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Protocol to Access White-Space (PAWS) Databases 
Abstract 


Portions of the radio spectrum that are allocated to licensees are 
available for non-interfering use. This available spectrum is called 
"white space". Allowing secondary users access to available spectrum 
"unlocks" existing spectrum to maximize its utilization and to 
provide opportunities for innovation, resulting in greater overall 
spectrum utilization. 


One approach to managing spectrum sharing uses databases to report 
spectrum availability to devices. To achieve interoperability among 
multiple devices and databases, a standardized protocol must be 
defined and implemented. This document defines such a protocol, the 
"Protocol to Access White-Space (PAWS) Databases". 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7545. 
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This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
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Introduction 


This section provides some high-level introductory material. Readers 
are strongly encouraged to read "Protocol to Access White-Space 
(PAWS) Databases: Use Cases and Requirements" [RFC6953] for use 
cases, requirements, and additional background. 


A geospatial database can track available spectrum (in accordance 
with the rules of one or more regulatory domains) and make this 
information available to devices. This approach shifts the 
complexity of spectrum-policy conformance out of the device and into 
the database. This approach also simplifies adoption of policy 
changes, limiting updates to a handful of databases, rather than 
numerous devices. It opens the door for innovations in spectrum 
management that can incorporate a variety of parameters, including 
user location and time. In the future, it also can include other 
parameters, such as user priority, signal type and power, spectrum 
supply and demand, payment or micro-auction bidding, and more. 


In providing this service, a database records and updates information 
necessary to protect primary users -- for example, this information 
may include parameters such as a fixed transmitter's call sign, its 
geolocation, antenna height, power, and periods of operation. The 
rules that the database is required to follow, including its schedule 
for obtaining and updating protection information, protection rules, 
and information reported to devices, vary according to regulatory 
domain. Such variations, however, should be handled by each database 
and hidden from devices to the maximum extent possible. 


This specification defines an extensible protocol, built on top of 
HTTP and TLS, to obtain available spectrum from a geospatial database 
by a device with geolocation capability. It enables a device to 
operate in a regulatory domain that implements this protocol. 


Conventions and Terminology 
1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in "Key words for use in 
RFCs to Indicate Requirement Levels" [RFC2119]. 


Chen, et al. Standards Track [Page 5] 


RFC 7545 PAWS May 2015 


2.2. Terminology 


Database or Spectrum Database: A Database is an entity that contains 
current information about available spectrum at a given location 
and time, as well as other types of information related to 
spectrum availability and usage. 


Device ID: An identifier for a device. 
EIRP: Effective Isotropically Radiated Power 


ETSI: European Telecommunications Standards Institute 
(http://www.etsi.org) 


FCC: The U.S. Federal Communications Commission 
(http: //www.fcc.gov) 


Listing server: A server that provides the URIs for one or more 
Spectrum Databases. A regulator, for example, may operate a 
Database Listing Server to publish the list of authorized Spectrum 
Databases for its regulatory domain. 


Master Device: A device that queries the Database, on its own behalf 
and/or on behalf of a slave device, to obtain available spectrum 
information. 


Regulatory Domain: A location where certain rules apply to the use 
of white-space spectrum, including the operation of Databases and 
devices involved in its use. A regulatory domain is normally 
defined by a unit of government for a particular country, but PAWS 
is agnostic as to how a regulatory domain is constructed. 


Ruleset: A ruleset represents a set of rules that governs the 
operation of white-space devices and Spectrum Databases. A 
regulatory authority can define its own set of rules or adopt an 
existing ruleset. When a Database or device is said to "Support a 
ruleset", it means that it contains out-of-band knowledge of the 
rules and that its hardware and software implementations conform 
to those rules. 


Ruleset Identifier: A ruleset can be identified by an IANA- 
registered identifier (see PAWS Ruleset ID Registry 
(Section 9.1)). When a Database or device indicates it supports a 
ruleset identifier, it means that it conforms to the rules 
associated with that identifier. A regulatory authority can 
define and register its own ruleset identifiers, or it can use a 
previously registered identifier if it adopts an existing ruleset. 
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Slave Device: A device that queries the Database through a master 
device. 


3. Protocol Overview 


A Master Device uses PAWS to obtain a schedule of available spectrum 
at its location. The security necessary to ensure the accuracy, 
privacy, and confidentiality of the device’s location is described in 
the Security Considerations (Section 10). This document assumes that 
the Master Device and the Database are connected to the Internet. 


A typical sequence of PAWS operations is outlined as follows. See 
"Protocol Functionalities" (Section 4) and "Protocol Parameters" 
(Section 5) for details: 


Vu The Master Device obtains (statically or dynamically) the URI 
for a Database appropriate for its location, to which to send 
subsequent PAWS messages. 


2. The Master Device establishes an HTTPS session with the 
Database. 
3 The Master Device optionally sends an initialization message to 


the Database to exchange capabilities. 


4. If the Database receives an initialization message, it responds 
with an initialization-response message in the body of the HTTP 
response. 

5s The Database may require the Master Device to be registered 


before providing service. 


6. The Master Device sends an available-spectrum request message to 
the Database. The message may be on behalf of a Slave Device 
that made a request to the Master Device. 


7. If the Master Device is making a request on behalf of a Slave 
Device, the Master Device may verify with the Database that the 
Slave Device is permitted to operate. 


8. The Database responds with an available-spectrum response 
message in the body of the HTTP response. 
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9: The Master Device may send a spectrum-usage notification message 
to the Database. The notification is purely informational; it 
notifies the Database what spectrum the Master Device intends to 
use and is not a request to the Database to get permission to 
use that spectrum. Some Databases may require spectrum-usage 
notification. 


10. If the Database receives a spectrum-usage notification message, 
it responds by sending the Master Device a spectrum-usage 
acknowledgement message. Since the notification is purely 
informational, the Master Device does not need to process the 
database response. 


Different regulatory domains may impose particular requirements, such 
as requiring Master Devices to register with the Database, performing 
Slave Device verification, and sending spectrum-usage notifications. 


3.1. Multi-ruleset Support 


For a Master Device that supports multiple rulesets and operates with 
multiple Databases, PAWS supports the following sequence of 
operations for each request by the Master Device: 


1. The Master Device includes in its request its location and 
optionally includes the identifier of all the rulesets it 
supports and any parameter values it might need for the request. 


2. The Database uses the device location and also may use the 
ruleset list to determine its response, for example, to select 
the list of required parameters. 


3. If required parameters are missing from the request, the Database 
responds with an error and a list of names of the missing 
parameters. 

4. The Master Device makes the request again, adding the missing 


parameter values. 


5. The Database responds to the request, including the identifier of 
the applicable ruleset. 


6. The Master Device uses the indicated ruleset to determine how to 
interpret the database response. 


NOTE: Some regulatory domains specify sets of requirements for device 
behavior that may be complex and not easily parameterized. The 
ruleset-id parameter provides a mechanism for the Database to inform 
the Master Device of an applicable ruleset, and, for devices with 
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out-of-band knowledge of the particular regulatory domain 
requirements, to satisfy those requirements without having to specify 
the device-side behavior within the protocol. Ruleset identifiers 
will normally contain the name of the regulatory body that 
established the rules and version information, such as 
"FccTvBandWhiteSpace-2010". 


By separating the regulatory "authority" from the "ruleset-id", it 
allows the protocol to support multiple regulatory authorities that 
use the same device-side ruleset. It also allows support for a 
single authority to define multiple rulesets. 


4. Protocol Functionalities 


PAWS consists of several components. As noted below, some regulatory 
domains or database implementations may mandate the use of a 
component, even when its use is not mandated by PAWS. 


o Database Discovery (Section 4.1) is a required component for the 
Master Device. 


o Initialization (Section 4.3) is a required component for the 
Database. Its use allows the Master Device to determine necessary 
information that has not been preconfigured. 


o Device Registration (Section 4.4) is an optional component for the 
Database. It can be implemented as a separate component or as 
part of the Available Spectrum Query (Section 4.5) component. It 
is used by the Master Device when the Database requires it. Note 
that some regulators require device registration for only specific 
device types, such as higher-power fixed (as opposed to mobile) 
devices, to allow them to contact the operators to resolve any 
interference issues. 


o Available Spectrum Query (Section 4.5) is a required component for 
the Master Device and the Database. 


o Spectrum Use Notify (Section 4.5.5) is an optional component for 
the Master Device and the Database. When it is required, the 
Database informs the Master Device via its response to the 
Available Spectrum Query (Section 4.5). 


o Device Validation (Section 4.6) as a separate component is 
optional for the Master Device and Database. When implemented by 
the Database, its use allows the Master Device to validate Slave 
Devices without having to use the full Available Spectrum Query. 
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This section describes the protocol components and their messages. 
"Protocol Parameters" (Section 5) contains a more thorough discussion 
of the parameters that make up the PAWS request and response 
messages. "Message Encoding" (Section 6) provides examples of 
message encodings. "HTTPS Binding" (Section 7) describes the use of 
HTTPS ("HTTP Over TLS" [RFC2818]) for transferring PAWS messages and 
optional device authentication. 


The parameter tables in this section and "Protocol Parameters" 
(Section 5) are for reference and contain the name of each parameter, 
the data type of each parameter, and whether the existence of the 
parameter is required for the protocol transaction in question. The 
diagrams are loosely based on the Unified Modeling Language (UML), 
and the data types are defined either in "Protocol Parameters" 
(Section 5) or are one of the following primitive or structured 
types: 


string: A string, as defined by JSON [RFC7159], restricted to the 
UTF-8 encoding. 


int: A number, as defined by JSON [RFC7159], without a fractional or 
exponent part. 


float: A number, as defined by JSON [RFC7159]. 
boolean: A boolean, as defined by JSON [RFC7159]. 


list: A structured type that represents a list of elements, as 
defined by JSON [RFC7159] array type. All elements of the list 
are of the same data type, which is indicated in its diagram and 
description. The diagram notation and description may include 
additional constraints, such as minimum or maximum number of 


elements. 
Also: 
o All parameter names are case sensitive. Unless stated otherwise, 


all string values are case sensitive. 


o All timestamps are in UTC and are expressed using exactly the 
form, YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the 
Internet: Timestamps" [RFC3339]. 


In some cases, specific rulesets may place additional requirements on 
message parameters. These additional requirements will be documented 
in the IANA PAWS Ruleset ID Registry (Section 9.1). When a request 

message sent to the Database has missing parameters, whether they are 
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required by PAWS or the applicable ruleset, the Database returns the 
MISSING error (see Section 5.17.3), along with data indicating the 
missing parameters. 


4.1. Database Discovery 
4.1.1. Preconfiguration 


The Master Device can be provisioned statically (preconfigured) with 
the URI of one or more Databases. For example, in a particular 
regulatory domain, there may be a number of certified Databases that 
any device operating in that domain is permitted to connect to, and 
those URIS can be preconfigured in the device. 


Listing Server Support: As an alternative to preconfiguring devices 
with a list of certified Databases, some regulatory domains support 
the preconfiguration of devices with the URI of a certified listing 
server, to which devices can connect to obtain the list of certified 
Databases. See "Database Listing Server Support" (Appendix A) for 
further information. 


4.1.2. Configuration Update: Database URI Changes 


To adapt to changes in the list of certified or approved Databases, 
the device needs to update its preconfigured list of Databases. 


A Database MAY change its URI, but before it changes its URI, it MUST 
indicate the upcoming change by including the URI of one or more 
alternate Databases using DbUpdateSpec (Section 5.7) in its responses 
to devices. The Database MUST reply with DbUpdateSpec for a minimum 
of 2 weeks before disabling the old URI. A device will update its 
preconfigured entry for the Database sending the DbUpdateSpec by 
replacing this entry with the alternate Databases listed in the 
DbUpdateSpec; the list of alternate Databases does not affect any 
other entries. Note that the ordering of Databases in the list does 
not imply any preference and does not need to remain the same for 
every request. The device SHOULD detect infinite redirection loops; 
if a suitable Database cannot be contacted, the device MUST treat 
this as equivalent to a response indicating no available spectrum. 
This database-change mechanism is used, for example, before a 
Database ceases operation; it is not intended to be used for dynamic 
load balancing. 
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4.1.3. Error Handling 


The device SHOULD select another Database from its list of 
preconfigured Databases if: 


o The selected Database is unreachable or does not respond. 


o The selected Database returns an UNSUPPORTED error (see "Error 
Codes" (Section 5.17)), which indicates the Database does not 
support the device (based on its device type, model, etc.) or 
supports none of the rulesets specified in the request. 


If a suitable Database cannot be contacted, the device MUST treat 
this as equivalent to a response indicating no available spectrum. 

If the device had previously contacted a Database to get available 
spectrum, but subsequently fails to contact a suitable Database, the 
spectrum the device is currently using can be used for as long as the 
spectrum data is valid. However, after that period, the device will 
no longer have valid spectrum to use. Some regulatory domains may 
have specific rules regarding how long the spectrum data remains 
valid in these cases. 


4.2. PAWS Version 


PAWS version uses a "<major>.<minor>" numbering scheme to indicate 
versions of the protocol. The protocol versioning policy is intended 
to allow the device or Database to indicate the format of a message 
and its understanding of PAWS functionality defined by that version. 
No change is made to the version string for the addition of message 
components that only add to extensible parameter values. The <minor> 
number is incremented when the changes made to the protocol add 
functionalities (methods) but do not change the existing 
functionalities. The <major> number is incremented when incompatible 
changes are made to existing functionality. 


The current PAWS version is "1.0". 
4.3. Initialization 


A Master Device SHOULD use the initialization procedure to exchange 
capability information with the Database whenever the Master Device 
powers up or initiates communication with the Database. The 
initialization response informs the Master Device of specific 
parameterized-rule values for each supported ruleset, such as 
threshold distances and time periods beyond which the device must 
update its available-spectrum data (see "RuleSetInfo" (Section 5.6)). 
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When parameterized-rule values are not preconfigured for the 
applicable ruleset at the specified location, a Master Device MUST 
use the initialization procedure. 


It is important to note that, when parameterized-rule values are 
preconfigured in a Master Device, they are preconfigured on a per- 
ruleset basis. That is, values preconfigured for one ruleset are not 
applicable to any other ruleset. 


For database implementations that require it, the initialization 
message also enables extra database-specific or ruleset-specific 
handshake parameters to be communicated before allowing available- 
spectrum requests. 

The Initialization request procedure is depicted in Figure 1. 


o INIT REO (Section 4.3.1) is the initialization request message 


o INIT RESP (Section 4.3.2) is the initialization response message 


ii EE + Hest SS Ra SS SSeS se + 
| Master Device | | Spectrum Database | 
A + AZ E + 
| | 
| INIT REQ 
| >| 
| | 
INIT_RESP 
Km === === === o 
| | 
Figure 1 


4.3.1. INIT_REO 


The initialization request message allows the Master Device to 
initiate exchange of capabilities with the Database. 


$--------------------------------------- - 
| INIT_REQ 

4---------------------------- 4---------- 

|deviceDesc:DeviceDescriptor | REQUIRED | 
| location:GeoLocation | REQUIRED | 
B | OPTIONAL | 
4---------------------------- 4---------- * 
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Parameters: 


deviceDesc: The DeviceDescriptor (Section 5.2) for the device is 
REQUIRED. If the device descriptor does not contain any ruleset 
IDs, the Master Device is asking the Database to return a 
RulesetInfo (Section 5.6) list that specifies the rulesets that it 
supports at the specified location. 


location: The GeoLocation (Section 5.1) of the device is REQUIRED. 
If the location is outside all regulatory domain supported by the 
Database, the Database MUST respond with an OUTSIDE_COVERAGE error 
(see Table 1). 


other: The Master Device MAY specify additional handshake parameters 
in the INIT_REQ message. The Database MUST ignore all parameters 
it does not understand. To simplify its initialization logic, a 
Master Device that supports multiple Databases and rulesets can 
include the union of all required parameters for all its supported 
rulesets. Consult the PAWS Parameters Registry (Section 9.2) for 
possible additional parameters. 


2e INIT RESP 

The initialization response message communicates database parameters 
to the requesting device. This response is returned only when there 
is at least one ruleset. Otherwise, the Database returns an error 


response, as described in INIT REQ (Section 4.3.1). 


A O ieina a + 

| INIT_RESP | 

AO O nenene do + Lot tes=========2= + 
| rulesetInfos:list | REQUIRED |------- >| RulesetInfo 
|databaseChange:DbUpdateSpec | OPTIONAL | RSS $ 
*other:any | OPTIONAL 

pee ee ee ee eee posta + 

Parameters: 


rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in 
the response. Each RulesetInfo corresponds to a ruleset supported 
by the Database and is applicable to the location specified in the 
INIT_REQ (Section 4.3.1) message. 


If the device included a list of ruleset IDs in the 
DeviceDescriptor of its INIT_REQ message, each RulesetInfo in the 
response MUST match one of the specified ruleset IDs. 
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If the DeviceDescriptor did not contain any ruleset IDs, the 
Database SHOULD include in the rulesetInfos list a RulesetInfo for 
each ruleset it supports at the specified location. 


If the Database does not support the device or supports none of 
the rulesets specified in the DeviceDescriptor, it MUST instead 
return an error with the UNSUPPORTED code (see Table 1) in the 
error response. 


databaseChange: The Database MAY include a DbUpdateSpec 
(Section 5.7) to notify the Master Device of a change to the 
database URI, providing one or more alternate database URIs. The 
device needs to update its preconfigured entry for the responding 
Database with the alternate Databases listed in the DbUpdateSpec. 


other: The Database MAY include additional handshake parameters in 
the INIT_RESP (Section 4.3.2) message. The Master Device MUST 
ignore all parameters it does not understand. Consult the PAWS 
Parameters Registry (Section 9.2) for possible additional 
parameters. 


4.4. Device Registration 


Some rulesets require a Master Device to send its registration 
information to the Database in order to establish certain operational 
parameters. FCC rules, for example, require that a 'Fixed Device’ 
register its owner and operator contact information, its device 
identifier, its location, and its antenna height (see FCC CFR47-15H 
[FCC-CFR47-15H]). 


The Database MAY implement device registration as a separate Device 
Registration request, or as part of the available-spectrum request. 
If the Database does not implement a separate Device Registration 
request, it MUST return an error with the UNIMPLEMENTED code (see 
Table 1) in the error-response message. 


The Device Registration request procedure is depicted in Figure 2. 


o REGISTRATION REQ (Section 4.4.1) is the device-registration 
request message 


o REGISTRATION_RESP (Section 4.4.2) is the device-registration 
response message 
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4.4.1. REGISTRATION_REQ 


The registration request message contains the required registration 
parameters. A parameter marked as optional may be required by some 


rulesets. 
4------------------------------------------- + 
| REGISTRATION_REQ | 
$ 4+----------- + 
| deviceDesc:DeviceDescriptor | REQUIRED | 
| location:GeoLocation | REQUIRED | 
| deviceOwner:DeviceOwner | OPTIONAL | 
lantenna:AntennaCharacteristics | OPTIONAL | 
| *other:any | OPTIONAL | 
4------------------------------- 4----------- + 
Parameters: 

deviceDesc: The DeviceDescriptor (Section 5.2) for the Master Device 


is REQUIRED. The ruleset IDs included in the DeviceDescriptor 
indicate the rulesets for which the device wishes to register. 


location: The GeoLocation (Section 5.1) for the device is REQUIRED. 
More precisely, this is the location at which the device intends 
to operate. If the location is outside all regulatory domains 
supported by the Database, the Database MUST respond with an 
OUTSIDE_COVERAGE error (see Table 1). 


deviceOwner: The DeviceOwner (Section 5.5) information is OPTIONAL. 
Some rulesets may require deviceOwner information under certain 
conditions. See PAWS Ruleset ID Registry (Section 9.1) for 
ruleset-specific requirements. 


antenna: The AntennaCharacteristics (Section 5.3) is OPTIONAL. 
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other:  Rulesets and database implementations may require additional 


registration parameters. To simplify its registration logic, the 
Master Device MAY send a union of the registration information 
required by all supported rulesets. The Database MUST ignore all 
parameters it does not understand. Consult the PAWS Parameters 
Registry (Section 9.2) for possible additional parameters. 


.2. | REGISTRATION RESP 


The registration response message acknowledges successful 
registration by including a RulesetInfo message for each ruleset in 


which the registration is accepted. If the Database accepts the 


registration for none of the specified rulesets, the Database MUST 
return the NOT REGISTERED error (see "Error Codes" (Section 5.17)). 


4--------------------------------------- t 

|REGISTRATION RESP | 

$ 4---------- t l1..* 4------------- + 
| rulesetInfos:list | REQUIRED |------- >| RulesetInfo 

| databaseChange : DbUpdateSpec | OPTIONAL | F===23 SHE SPSS + 
| *other:any | OPTIONAL | 
4---------------------------- 4---------- t 

Parameters: 


rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in 
the response. Each entry corresponds to a ruleset for which the 
registration was accepted. The list MUST contain at least one 
entry. 


Each RulesetInfo in the response MUST match one of the ruleset IDs 
Specified in the DeviceDescriptor of REGISTRATION REQ. 


If the Database does not support the device or supports none of 
the rulesets specified in the DeviceDescriptor, it MUST instead 
return an error with the UNSUPPORTED code (see Table 1) in the 
error response. 


databaseChange: The Database MAY include a DbUpdateSpec 
(Section 5.7) to notify the Master Device of a change to the 
database URI, providing one or more alternate database URIs. The 
device needs to update its preconfigured entry for the responding 
Database with the alternate Databases listed in the DbUpdateSpec. 
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other: Database implementations MAY return additional parameters in 
the registration response. The Master Device MUST ignore any 
parameters it does not understand. Consult the PAWS Parameters 
Registry (Section 9.2) for possible additional parameters. 


4.5. Available Spectrum Query 


To obtain the available spectrum from the Database, a Master Device 
sends a request that contains its geolocation and any parameters 
required by the ruleset (such as device identifier, capabilities, and 
characteristics). The Database returns a response that describes 
which frequencies are available, at what permissible operating power 
levels, and a schedule of when they are available. 


The Available Spectrum Query procedure is depicted in Figure 3. 


o AVAIL SPECTRUM REQ (Section 4.5.1) is the available-spectrum 
request message. 


o AVAIL SPECTRUM RESP (Section 4.5.2) is the available-spectrum 
response message. 


o AVAIL_SPECTRUM_BATCH_REQ (Section 4.5.3) is an OPTIONAL batch 
version of the available-spectrum request message that allows 
multiple locations to be specified in the request. 


o AVAIL SPECTRUM BATCH RESP (Section 4.5.4) is the response message 
for the batch version of the available-spectrum request that 
contains available spectrum for each location in the request. 


o SPECTRUM USE NOTIFY (Section 4.5.5) is the spectrum-usage 
notification message. 


o SPECTRUM USE RESP (Section 4.5.6) is the spectrum-usage 
acknowledgment message. 
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AVAIL_SPECTRUM_REQ 
(AVAIL_SPECTRUM_BATCH_REQ) 


| 
| 
| 
| 

AVAIL SPECTRUM RESP 
| (AVAIL SPECTRUM BATCH RESP) 
| 
| 
| 
| 
| 


«----------2-2-2-22--2---------- | 
(SPECTRUM USE NOTIFY) | 
A ES E LEER >| 
(SPECTRUM_USE_RESP) 
< Sa Ne i ae A a REPRE o NE + 
Figure 3 
1. First, the Master Device sends an available-spectrum request 


message to the Database. 


2. The Database MUST respond with an error using the NOT REGISTERED 
code (see Table 1) if: 


* registration information is required, and 
* the request does not include registration information, and 
* the device has not previously registered with the Database 


3. If the location specified in the request is outside the 
regulatory domain supported by the Database, the Database MUST 
respond with an OUTSIDE COVERAGE error (see Table 1). If some, 
but not all, locations within a batch request are outside the 
regulatory domain supported by the Database, the Database MUST 
return an OK response with available spectrum for only the valid 
locations; otherwise, if all locations within a batch request are 
outside the regulatory domain, the Database MUST respond with an 
OUTSIDE_COVERAGE error. 
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4. The Database MAY perform other validation of the request, (e.g., 


checking for missing required parameters or authorizations). If 
validation fails, the Database returns an appropriate error code 
(Table 1). If the request is missing required parameters, the 


Database MUST respond with a MISSING error (see Table 1) and 
SHOULD include a list of the missing parameters. 


5. If the request is valid, the Database responds with an available- 
spectrum response message. If the ruleset requires that devices 
must report anticipated spectrum usage, the Database will 
indicate so in the response message. 


6. If the available-spectrum response indicates that the Master 
Device must send a spectrum-usage notification message, the 
Master Device sends the notification message to the Database. 
Even when not required by the Database, the Master Device MAY 
send a notification message. 


7. If the Database receives a spectrum-usage notification message, 
it MUST send a spectrum-usage acknowledgment message to the 
Master Device. 


The procedure for a Master Device to ask for available spectrum on 
behalf of a Slave Device is similar, except that the process is 
initiated by the Slave Device. The device identifier, capabilities, 
and characteristics communicated in the AVAIL SPECTRUM REQ message 
MUST be those of the Slave Device, and: 


o The "masterDeviceLocation" field specifying the location of the 
Master Device is REQUIRED. 


o The "location" field specifying the location of the Slave Device 
is OPTIONAL, since the Slave Device may not have location-sensing 
capabilities. 


Although the communication and protocol between the Slave Device and 
Master Device are outside the scope of this document (represented as 
dotted lines), the expected message sequence is shown in Figure 4. 
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| 

| 

| 

| oe 
| | AVAIL_SPECTRUM_RESP | 
| [k= | 
| AVAIL_SPEC_RESP | | 
ESA | | 
| | | 

(SPECTRUM_USE) 

| ig RM Uim na > (SPECTRUM_USE_NOTIFY) | 
| BENE í 
| | (SPECTRUM_USE_RESP) | 
| | | 
| | | 


4.5.1. AVAIL_SPECTRUM_REQ 


The request message for the Available Spectrum Query protocol MUST 
include a geolocation. Rulesets may mandate that it be the device’s 
current location or allow it to be an anticipated location. A 
parameter marked as optional may be required by some rulesets. 


sn + 
|AVAIL SPECTRUM REQ | 
R-—-------------------------------- 4R-—--------------- * 
|deviceDesc:DeviceDescriptor | see description | 
| location:GeoLocation | see description | 
| owner :DeviceOwner | OPTIONAL | 
|antenna:AntennaCharacteristics | OPTIONAL | 


capabilities:DeviceCapabilities OPTIONAL 
masterDeviceDesc:DeviceDescriptor OPTIONAL 
|masterDeviceLocation:GeoLocation see description | 
[requestType:string OPTIONAL 


| *other:any 
de s===3 535 SSS Sas SSeS SS SSS SSseSS= $ eseneern nne + 
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Parameters: 


deviceDesc: The DeviceDescriptor (Section 5.2) for the device 

requesting available spectrum. When the request is made by a 
Master Device on its own behalf, the descriptor is that of the 
Master Device, and it is REQUIRED. When the request is made on 
behalf of a Slave Device, the descriptor is that of the Slave 
Device, and it is REQUIRED if the "requestType" parameter is not 
specified. The deviceDesc parameter may be OPTIONAL for some 
values of requestType. 


location: The GeoLocation (Section 5.1) for the device requesting 
available spectrum. More precisely, this is the location at which 
the device intends to operate. When the request is made by the 
Master Device on its own behalf, the location is that of the 
Master Device, and it is REQUIRED. When the request is made by 
the Master Device on behalf of a Slave Device, the location is 
that of the Slave Device, and it is OPTIONAL (see also 


masterDeviceLocation). The location may be an anticipated 
position of the device to support mobile devices, but its use 
depends on the ruleset. If the location specifies a region, 


rather than a point, the Database MAY return an error with the 
UNIMPLEMENTED code (see Table 1), if it does not implement query 
by region. 


NOTE: Technically, this is the location of the radiation center of 
the device’s antenna, but that distinction may be relevant only 
for fixed devices. 


owner: The DeviceOwner (Section 5.5) information MAY be included to 
register the device with the Database. This enables the device to 
register and get spectrum-availability information in a single 
request. Some rulesets mandate registration for specific device 
types. 


antenna: The AntennaCharacteristics (Section 5.3) is OPTIONAL. 


capabilities: The Master Device MAY include its DeviceCapabilities 
(Section 5.4) to limit the available-spectrum response to the 
spectrum that is compatible with its capabilities. The Database 
SHOULD NOT return spectrum that is not compatible with the 
specified capabilities. 


masterDeviceDesc: When the request is made by the Master Device on 


behalf of a Slave Device, the Master Device MAY provide its own 
descriptor. 
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masterDeviceLocation: When the request is made by the Master Device 
on behalf of a Slave Device, the Master Device MUST provide its 
own GeoLocation (Section 5.1). 


requestType: The request type is OPTIONAL; it may be used to modify 
the request, but its use depends on the applicable ruleset. The 
request type may be used, for example, to indicate that the 
response should include generic Slave Device parameters without 
having to specify the device descriptor for a specific device. 
When requestType is missing, the request is for a specific device 
(Master or Slave), so deviceDesc is REQUIRED. The maximum length 
of the value is 64 octets. See the specifics in the Initial 
Registry Contents (Section 9.1.2) for the Ruleset ID Registry. 


other: Rulesets and database implementations may require additional 
request parameters. The Database MUST ignore all parameters it 
does not understand. Consult the PAWS Parameters Registry 
(Section 9.2) for possible additional parameters. 


4.5.2. | AVAIL SPECTRUM RESP 


The response message for the Available Spectrum Query contains one or 
more SpectrumSpec (Section 5.9) elements, one for each ruleset 
supported at the location specified in the corresponding 

AVAIL SPECTRUM REQ (Section 4.5.1) message. Each SpectrumSpec 
element contains a list of one or more spectrum schedules, 
representing permissible power levels over time: 


o Each spectrum schedule specifies the permissible power level for a 
duration defined by a pair of start and stop times. The power 
levels refer to permissible EIRP over a resolution bandwidth. 


o Within each list of schedules, event-time intervals MUST be 
disjoint and MUST be sorted in increasing time. 


o A gap in the time schedule means no spectrum is available for that 
time interval. 


Consider a Database that provides a schedule of available spectrum 
for the next 24 hours. If spectrum availability were to be different 
at different times of day, the response would contain a list of 
Schedules, each transition representing some change to the spectrum 
availability. A device might use different strategies to select 
which spectrum to use, e.g.: 


o Always use the frequencies that permit the highest power 
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o Use the frequencies that are available for the longest period of 
time. 
o Just use the first set of frequencies that matches its needs. 
4--------------------------------------- + 
|AVAIL SPECTRUM RESP | 
+---------------------------- 4---------- + 


timestamp:string 
deviceDesc:DeviceDescriptor REQUIRED 


REQUIRED 


pos | REQUIRED | poc + 
ner M MUT oe lis ee red | 
|databaseChange:DbUpdateSpec | OPTIONAL | | 
| *other: any | OPTIONAL | | 
+---------------------------- +---------- + [Ly A 
V 
4R----------------------------------- + 
| Spect rumSpec | 
+------------------------ 4---------- + 
[rulesetInfo:RulesetInfo | REQUIRED | 
|spectrumSchedules:list | REQUIRED |-+ 
timeRange:EventTime OPTIONAL 
frequencyRanges:list OPTIONAL 
|needsSpectrumReport:bool| OPTIONAL | | 
[maxTotalBwHz: float | OPTIONAL | | 
[maxContiguousBwHz: float | OPTIONAL | | 
4------------------------ 4---------- + | 
4-------------------- + 
ee ee 
V 
4------------------------------- + 
| SpectrumSchedule | 
4-------------------- 4---------- + 
eventTime:EventTime REQUIRED 
spectra:list REQUIRED 
4-------------------- 4---------- + 


Parameters: 


timestamp: Timestamp of the response is expressed in UTC using the 
form, YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the 
Internet: Timestamps" [RFC3339]. This can be used by the device 
as a reference for the start and stop times in the spectrum 
schedules. 


deviceDesc: The Database MUST include the DeviceDescriptor 
(Section 5.2) specified in the AVAIL_SPECTRUM_REQ message. 
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spectrumSpecs: The SpectrumSpec (Section 5.9) list MUST include at 
least one entry. Each entry contains the schedules of available 
spectrum for a ruleset. The Database MAY return more than one 
SpectrumSpec to represent available spectrum for multiple rulesets 
at the specified location. 


databaseChange: The Database MAY include a DbUpdateSpec 
(Section 5.7) to notify the device of a change to the database 
URI, providing one or more alternate database URIs. The device 
needs to update its preconfigured entry for the responding 
Database with the alternate Databases listed in the DbUpdateSpec. 


other: Database implementations MAY return additional parameters in 
the response. The device MUST ignore any parameters that it does 
not understand. Consult the PAWS Parameters Registry 
(Section 9.2) for possible additional parameters and requirements 
they place on the device. 


4.5.2.1. Update Requirements 


When the stop time specified in the schedule has been reached, the 
device: 


o MUST obtain a new spectrum-availability schedule, either by using 
the next one in the list (if provided) or making another Available 
Spectrum Query (Section 4.5). 


o If the device is unable to contact the Database to obtain a new 
schedule, it MUST treat this as equivalent to a response with no 
available spectrum. 


Some rulesets also mandate that a device must obtain a new spectrum- 
availability schedule if the device moves beyond a threshold distance 
(established by the ruleset) from the actual location and all 
anticipated location(s) it reported in previous AVAIL_SPECTRUM_REQ or 
AVAIL_SPECTRUM_BATCH_REQ messages (see "maxLocationChange" in 
RulesetInfo (Section 5.6)). If the device is unable to contact the 
Database to obtain a new schedule, it MUST treat this as equivalent 
to a response with no available spectrum. 


NOTE: The ruleset determines required device behavior when spectrum 
is no longer available. The ruleset also governs whether a device 
may request and use spectrum at anticipated locations beyond the 
threshold distance from its current location. 
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4.5.3. AVAIL_SPECTRUM_BATCH_REQ 


The Database MAY implement the batch request that allows multiple 
locations to be specified. This enables a portable Master Device, 
for example, to get available spectrum for a sequence of anticipated 
locations using a single request. The Database interprets each 
location in the batch request as if it were an independent request 
and returns results consistent with multiple individual 
AVAIL_SPECTRUM_REQ (Section 4.5.1) messages, but it returns these 


results in a batched response (Section 4.5.4). The request message 
for the batch Available Spectrum Query protocol MUST include at least 
one GeoLocation (Section 5.1). If the Database does not implement 


batch requests, it MUST return an UNIMPLEMENTED error (see Table 1). 


NOTE: Whether anticipated locations are allowed depends on the 
specified ruleset. A parameter marked as optional may be required by 
some rulesets. 


4--------------------------------------------------- + 
|AVAIL SPECTRUM BATCH REQ | 
4--------------------------------- 4----------------- t 
deviceDesc:DeviceDescriptor see description 
locations:list REQUIRED --+ 
| owner :DeviceOwner | OPTIONAL | | 
|antenna:AntennaCharacteristics | OPTIONAL | 
|capabilities:DeviceCapabilities | OPTIONAL | | 
|masterDeviceDesc:DeviceDescriptor| OPTIONAL | 
masterDeviceLocation:GeoLocation | see description | 
requestType:string OPTIONAL 
PS scu EE uou UA iE due is d TUN + | 
| *other: any | OPTIONAL | | 
4--------------------------------- 4----------------- + | 
| 
l.l y 
4------------- + 
GeoLocation | 
+------------- + 
Parameters: 
deviceDesc: The DeviceDescriptor (Section 5.2) for the device 


requesting available spectrum. When the request is made by a 
Master Device on its own behalf, the descriptor is that of the 
Master Device, and it is REQUIRED. When the request is made on 
behalf of a Slave Device, the descriptor is that of the Slave 
Device, and it is REQUIRED if the "requestType" parameter is not 
specified. The deviceDesc parameter may be OPTIONAL for some 
values of requestType. 
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locations: The GeoLocation (Section 5.1) list for the device is 


REQUIRED. This allows the device to specify its actual location 
plus additional anticipated locations. At least one location MUST 
be included. This specification places no upper limit on the 
number of locations, but the Database MAY restrict the number of 
locations it supports by returning a response with fewer locations 
than specified in the request. If the locations specify regions, 
rather than points, the Database MAY return an error with the 
UNIMPLEMENTED code (see Table 1), if it does not implement query 
by region. When the request is made by a Master Device on its own 
behalf, the locations are those of the Master Device. When the 
request is made by the Master Device on behalf of a Slave Device, 
the locations are those of the Slave Device (see also 
masterDeviceLocation). 


owner: The DeviceOwner (Section 5.5) information MAY be included to 


register the device with the Database. This enables the device to 
register and get spectrum-availability information in a single 
request. Some rulesets mandate registration for specific device 
types. 


antenna: The AntennaCharacteristics (Section 5.3) is OPTIONAL. 


capabilities: The Master Device MAY include its DeviceCapabilities 


(Section 5.4) to limit the available-spectrum response to the 
spectrum that is compatible with its capabilities. The Database 
SHOULD NOT return spectrum that is not compatible with the 
specified capabilities. 


masterDeviceDesc: When the request is made by the Master Device on 


behalf of a Slave Device, the Master Device MAY provide its own 
descriptor. 


masterDeviceLocation: When the request is made by the Master Device 


on behalf of a Slave Device, the Master Device MUST provide its 
own GeoLocation (Section 5.1). 


requestType: The request type is an OPTIONAL parameter that may be 


Chen, 


used to modify the request, but its use depends on the applicable 
ruleset. The request type may be used, for example, to request 
generic Slave Device parameters without having to specify the 
device descriptor for a specific device. When the requestType 
parameter is missing, the request is for a specific device (Master 
or Slave), so deviceDesc is REQUIRED. The maximum length is 64 
octets. See the ruleset specifics in the Initial Registry 
Contents (Section 9.1.2) for the Ruleset ID Registry. 
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other: Rulesets and database implementations may require additional 
request parameters. The Database MUST ignore all parameters it 
does not understand. Consult the PAWS Parameters Registry 
(Section 9.2) for possible additional parameters. 


4.5.4. AVAIL SPECTRUM BATCH RESP 


The response message for the batch Available Spectrum Query contains 
a schedule of available spectrum for the device at multiple 


locations. 
HO + 
| AVAIL_SPECTRUM_BATCH_RESP 


+---------------------------- +---------- + 
|timestamp: string | REQUIRED | 
deviceDesc:DeviceDescriptor REQUIRED 


geoSpectrumSpecs:list | REQUIRED |------- + 
(iste E uA oan | | 
|databaseChange:DbUpdateSpec | OPTIONAL | | 
| *other:any | OPTIONAL | | 
4+---------------------------- 4+---------- + | O..* 
V 
ASS TS OS EOS ARA + 
| GeoSpect rumSpec | 
hae Sse SSeS SSeS eS ESTE ASS + 
|location:GeoLocation | REQUIRED | 
|spectrumSpecs: list | REQUIRED | 
quee "a a a I Ho + 
Parameters: 
timestamp: Timestamp of the response of the form, 
YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the 
Internet: Timestamps" [RFC3339]. This can be used by the device 
as a reference for the start and stop times in the spectrum 
schedules. 
deviceDesc: The Database MUST include the DeviceDescriptor 


(Section 5.2) specified in the AVAIL SPECTRUM BATCH REQ message. 


geoSpectrumSpecs: The geoSpectrumSpecs (Section 5.15) list is 
REQUIRED (although it MAY be empty if spectrum is unavailable). 
For each location, the Database MAY return one or more 
SpectrumSpecs (Section 5.9) to represent available spectrum for 
one or more rulesets. The Database MAY return available spectrum 
for fewer locations than requested. The order of the entries in 
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the list is not significant, and the device MUST use the location 
value in each GeoSpectrumSpec entry to match available spectrum to 
a location. 


databaseChange: The Database MAY include a DbUpdateSpec 
(Section 5.7) to notify the device of a change to the database 
URI, providing one or more alternate database URIs. The device 
needs to update its preconfigured entry for the responding 
Database with the alternate Databases listed in the DbUpdateSpec. 


other: Database implementations MAY return additional parameters in 
the response. Consult the PAWS Parameters Registry (Section 9.2) 
for possible additional parameters and requirements they place on 
the device. 


See "Update Requirements" (Section 4.5.2.1) for when the device must 
update its available spectrum data. 


4.5.5.  SPECTRUM USE NOTIFY 


The spectrum-use notification message indicates the spectrum 
anticipated to be used by the device. 


do 29 St 2 C E E + 

| SPECTRUM_USE_NOTIFY | 

depronto Soon 22295 $22 + 

| deviceDesc:DeviceDescriptor | REQUIRED | 

location:GeoLocation see description 

masterDeviceDesc:DeviceDescriptor| OPTIONAL 

|masterDeviceLocation:GeoLocation | see description | 

|spectra:list | REQUIRED l1 

| *other:any | OPTIONAL |. | 

4--------------------------------- 4----------------- + | 0..* 

V 

hes oe on ta I Puer * 
| Spectrum | 
S nan SS ae Se SSeS do + 
|resolutionBwHz:float | REQUIRED | 
|profiles:list | REQUIRED | 
AO O do + 
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Parameters: 


deviceDesc: The DeviceDescriptor (Section 5.2) for the device is 


REQUIRED. 


location: The GeoLocation (Section 5.1) for the device. When the 


notification is made by a Master Device on its own behalf, the 
location is that of the Master Device and is REQUIRED. When the 
notification is made by a Master Device on behalf of a Slave 
Device, the location is that of the Slave Device and is OPTIONAL 
but may be required by some rulesets. 


spectra: The Spectrum (Section 5.11) list is REQUIRED and specifies 


the spectrum anticipated to be used by the device; this includes 
profiles of frequencies and power levels. The list MAY be empty, 
if the device decides not to use any spectrum. For consistency, 
the resolution bandwidth value, "resolutionBwHz", MUST match that 
from one of the Spectrum (Section 5.11) elements in the 
corresponding AVAIL_SPECTRUM_RESP message, and the maximum power 
levels in the Spectrum element MUST be expressed as power (EIRP) 
over the specified "resolutionBwHz" value. The actual bandwidth 
to be used (as computed from the start and stop frequencies) MAY 
be different from the "resolutionBwHz" value. As an example, when 
the ruleset expresses maximum power spectral density in terms of 
maximum power over any 100 kHz band, then the "resolutionBwHz" 
value should be set to 100 kHz, even though the actual bandwidth 
used can be 20 kHz. 


masterDeviceDesc: When the notification is made by the Master Device 


on behalf of a Slave Device, the Master Device MAY provide its own 
descriptor. 


masterDeviceLocation: When the notification is made by the Master 


Device on behalf of a Slave Device, the Master Device MUST include 
its own GeoLocation (Section 5.1). 


other: Depending on the ruleset, other parameters may be required. 


Chen, 


To simplify its logic, the device MAY include the union of all 
parameters required by all supported rulesets. The Database MUST 
ignore all parameters it does not understand. 
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4.5.6. SPECTRUM_USE_RESP 


The spectrum-use response message simply acknowledges receipt of the 


notification. 

HO + 
| SPECTRUM_USE_RESP | 
HO +---------- + 


databaseChange:DbUpdateSpec | OPTIONAL 
| *other:any | OPTIONAL | 
$ 4---------- t 


Parameters: 


databaseChange: The Database MAY include a DbUpdateSpec 
(Section 5.7) to notify the device of a change to the database 
URI, providing one or more alternate database URIs. The device 
needs to update its preconfigured entry for the responding 
Database with the alternate Databases listed in the DbUpdateSpec. 


other: Database implementations MAY return additional parameters in 
the response. Consult the PAWS Parameters Registry (Section 9.2) 
for possible additional parameters. 


4.6. Device Validation 


A Slave Device needs a Master Device to ask the Database on its 
behalf for available spectrum. Depending on the ruleset, the Master 
Device also must validate with the Database that the Slave Device is 
permitted to operate. When the ruleset allows a Master Device to 
"cache" the available spectrum for a period of time, the Master 
Device may use the simpler Device Validation component, instead of 
the full Available Spectrum Query component, to validate a Slave 
Device. 


When validating one or more Slave Devices, the Master Device sends 
the Database a request that includes the device identifier -- and any 
other parameters required by the ruleset -- for each Slave Device. 
The Database MUST return a response with an entry for each device to 
indicate whether it is permitted to use the spectrum. 


A typical sequence for using the Device Validation request is 
illustrated in Figure 5, where the Master Device already has a valid 
set of available spectrum for Slave Devices. Note that the 
communication and protocol between the Slave Device and Master Device 
are outside the scope of this document. 
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o DEV VALID REQ (Section 4.6.1) is the device-validation request 
message. 


o DEV VALID RESP (Section 4.6.2) is the device-validation response 


message. 

*------------ + *--------------- + $ + 
|Slave Device | Master Device | Spectrum Database | 
*------------ * *--------------- * R------------------- * 


| 
| | 
| | 
| | 
| (RA > | 
| | DEV_VALID_RESP | 
| E rata sates | 
| AVAIL_SPEC_RESP | 
E c RC Mann | | 
| | | 

(SPECTRUM_USE) 

| eee eee eer as > (SPECTRUM_USE_NOTIFY) | 
| | 2 = >| 
| | | 
| | (SPECTRUM, USE RESP) | 
| |<-----------------=--------- | 


4.6.1.  DEV VALID REQ 


This request is used by a Master Device to determine which Slave 
Devices are permitted to operate. 


4-------------------------2-------2-2--2--------- * 
|DEV VALID REQ | 
4---------------------2--2--2--------- 4---------- * 
|deviceDescs:list | REQUIRED |---+ 
[masterDeviceDesc:DeviceDescriptor | OPTIONAL | 
4---------------------2--2--2--------- 4---------- + 
VUE 
4--------------2-------- + 
DeviceDescriptor 
+----------—-----—----—- + 
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Parameters: 


deviceDescs: A DeviceDescriptor (Section 5.2) list is REQUIRED; it 
specifies the list of Slave Devices that are to be validated. 


masterDeviceDesc: The Master Device MAY provide its own descriptor. 


4.6.2. DEV_VALID_RESP 


HO + 
| DEV_VALID_RESP | 
$---------------------------- 4---------- + 
|deviceValidities:list | REQUIRED |---- 
|databaseChange:DbUpdateSpec | OPTIONAL | | 
HO 4---------- * 
Ve ahs os 
HO + 
|DeviceValidity | 
HO 4---------- + 
|deviceDesc:DeviceDescriptor | REQUIRED | 
| isValid:boolean | REQUIRED | 
| reason:string | OPTIONAL | 
HO 4---------- * 


Parameters: 


deviceValidities: A DeviceValidities (Section 5.16) list is REQUIRED 
to report the list of Slave Devices and whether each listed device 
is valid. The number of entries MUST match the number of 


DeviceDescriptors (Section 5.2) listed in the DEV VALID REQ 
message. 


databaseChange: The Database MAY include a DbUpdateSpec 
(Section 5.7) to notify the device of a change to the database 
URI, providing one or more alternate database URIs. The device 
needs to update its preconfigured entry for the responding 
Database with the alternate Databases listed in the DbUpdateSpec. 
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5. Protocol Parameters 
This section presents more details of the parameters that make up the 
PAWS request and response messages. It also includes a subsection 
that defines response codes. 

5.1. GeoLocation 
GeoLocation is used to specify one of the following: 
o a single point with optional uncertainty 
o a region described by a polygon 
These are represented using geometric shapes defined in Section 5 of 
"GEOPRIV Presence Information Data Format Location Object" [RFC5491], 
where: 
o A "point" with uncertainty is represented using the Ellipse shape. 
o A region is represented using the Polygon shape. 
The coordinates are expressed using the WGS84 datum [WGS-84], and 
units are degrees or meters. GeoLocation MAY also include a 
confidence level, expressed as a percentage. The confidence and 


uncertainty parameters may be required by some rulesets (see also 
[RFC7459]). 
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The data model for GeoLocation is illustrated below: 


+—------------------------------------ + 
|GeoLocation | 
4+—------------------ +----------------- + 
|point:Ellipse | see description | 
| region:Polygon | see description 

| confidence:int | OPTIONAL | 
4+—------------------ +----------------- + 


Note: Point and region are mutually exclusive. Exactly one must 
be present. 


center:Point REQUIRED |--+ 
semiMajorAxis:float | OPTIONAL | 
| semiMinorAxis:float | OPTIONAL | 


lorientation:float | OPTIONAL | 
4--------------------------- + 
|Point | 
4R---------------- 4R---------- + 
|latitude:float | REQUIRED | 
|longitude:float | REQUIRED | 
4+---------------- 4+---------- + 
HZ + 
|Polygon | 
4------------------- 4+----------- + ALLA 4--------------------------- + 
|exterior:list | REQUIRED |------ >|Point 
4------------------- 4+----------- + 4R---------------- 4R---------- + 
|latitude:float | REQUIRED | 
|longitude:float | REQUIRED | 
4R---------------- R---------- * 
Parameters: 
point: If present, it specifies the GeoLocation as a point. 


Paradoxically, a "point" is parameterized using an Ellipse, where 
the center represents the location of the point and the distances 
along the major and minor axes represent the uncertainty. The 
uncertainty values may be required, depending on the ruleset. 
Exactly one of "point" or "region" MUST be present. 


region: If present, it specifies the GeoLocation as a region. 
Exactly one of "point" or "region" MUST be present. 
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center: The center refers to the location of a GeoLocation point and 
is represented as the center of an ellipse. 


latitude, longitude: Floating-point numbers that express the 
latitude and longitude in degrees using the WGS84 datum [WGS-84]. 


semiMajorAxis, semiMinorAxis: This OPTIONAL parameter expresses the 
location uncertainty, in meters. It is parameterized using 
distances along the major and minor axes of the ellipse. The 
default value for each parameter is 0. 


orientation: This defines the orientation of the ellipse, expressed 
as the rotation, in degrees, of the semi-major axis from North 
towards the East. For example, when the uncertainty is greatest 
along the North-South direction, orientation is 0 degrees; 
conversely, if the uncertainty is greatest along the East-West 
direction, orientation is 90 degrees. When orientation is not 
present, the default value is 0. 


exterior: When GeoLocation describes a region, the "exterior" 
parameter refers to a list of latitude and longitude points that 
represents the vertices of a polygon. The first and last points 
MUST be the same. Thus, a minimum of 4 points is required. The 
following polygon restrictions from [RFC5491] apply: 


* A connecting line SHALL NOT cross another connecting line of 
the same polygon. 


* The vertices MUST be defined in a counter-clockwise direction, 
looking at them from above. 


* The edges of a polygon are defined by the shortest path between 
two points in space (not a geodesic curve). Consequently, the 
length between two adjacent vertices SHOULD be restricted to a 
maximum of 130 km. 


* Polygon shapes SHOULD be restricted to a maximum of 15 vertices 
(16 points that includes the repeated vertex). 


Additionally, all vertices are assumed to be at the same altitude. 


confidence: The location confidence level, as a percentage, MAY be 
provided. When this parameter is not provided, the default value 
is 95. Valid values range from 0 to 100, but, in practice, 100% 
confidence is not achievable. The confidence value is meaningful 
only when GeoLocation refers to a point with uncertainty. 
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5.2. DeviceDescriptor 


The device descriptor contains parameters that identify the specific 
device, such as its manufacturer serial number, manufacturer’s ID, 
and any other device characteristics required by ruleset. 


4-------------------------------- + 
|DeviceDescriptor | 
4--------------------- 4+---------- + 
|serialNumber:string | OPTIONAL | 
[manufacturerId:string| OPTIONAL | 
[modelld:string | OPTIONAL | 1..* 

| culesetIds:list | OPTIONAL | ------ >string 
| *other: any | OPTIONAL | 
4--------------------- 4---------- + 

Parameters: 


serialNumber: The manufacturer’s device serial number is OPTIONAL, 
although rulesets typically require it. Its maximum length is 64 
octets. 


manufacturerld: The manufacturer's ID is OPTIONAL but may be 
required by some rulesets. This represents the name of the device 
manufacturer, and therefore ought to be consistent across all 
devices from the same manufacturer and distinct from that of other 
manufacturers. Its maximum length is 64 octets. 


modelld: The device’s model ID is OPTIONAL but may be required by 
some rulesets. Its maximum length is 64 octets. 


rulesetIds: The list of identifiers for rulesets supported by the 
device (see Ruleset ID Registry (Section 9.1)). A Database MAY 
require that the device provides this list before servicing the 
device requests. If the Database supports none of the rulesets 
specified in the list, the Database MAY refuse to service the 
device requests. See RulesetInfo (Section 5.6) for discussion on 
ruleset identifiers. If present, the list MUST contain at least 
one entry. 


other: Depending on the ruleset, other parameters may be required. 
The Database MUST ignore all parameters in the message it does not 
understand. See PAWS Parameters Registry (Section 9.2) for 
additional valid parameters and for the process for extending the 
message with more parameters. Additionally, see PAWS Ruleset ID 
Registry (Section 9.1) for the valid set of parameters for each 
ruleset. 
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5.3. AntennaCharacteristics 


Antenna characteristics provide additional information, such as the 
antenna height, antenna type, etc. Whether antenna characteristics 
must be provided in a request depends on the device type and ruleset. 
Additionally, a parameter marked as optional may be required by some 


rulesets. 
4------------------------------------ + 
|AntennaCharacteristics | 
4------------------------- 4---------- + 
|height:float | OPTIONAL | 
|heightType:enum | OPTIONAL | 
|heightUncertainty:float | OPTIONAL | 
*characteristics: OPTIONAL 
various 
4------------------------- 4+---------- + 
Parameters: 


height: The antenna height in meters. Note that the height may be 
negative. 


heightType: Valid values are: 
AGL - Above Ground Level (default) 
AMSL - Above Mean Sea Level 
heightUncertainty: The height uncertainty in meters. 


NOTE: Depending on the ruleset, additional antenna characteristics 
may be required, such as: 


o antenna direction 

o antenna radiation pattern 
o antenna gain 

o antenna polarization 


These are not defined by the base protocol but may be added to the 
PAWS Parameters Registry, as needed. 
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5.4. DeviceCapabilities 


Device capabilities provide additional information that may be used 
by the device to provide additional information to the Database that 
can help it to determine available spectrum. If the Database does 
not support device capabilities, it MUST ignore the parameter 


altogether. 
HO + 
|DeviceCapabilities | 
4--------------------- 4+--------- + 
pc poe l1 
| *other: any [OPTIONAL | | 
4--------------------- 4--------- + | 0..* 
V 
HO + 
|FrequencyRange | 
4+---------------------- 4+--------- + 
|startHz:float |REQUIRED | 
| stopHz:float |REQUIRED | 
4+---------------------- 4+--------- + 
Parameters: 


frequencyRanges: Optional FrequencyRange (Section 5.13) list. Each 
FrequencyRange element contains start and stop frequencies in 
which the device can operate. When specified, the Database SHOULD 
NOT return available spectrum that falls outside these ranges. 


other Consult the PAWS Parameters Registry (Section 9.2) for 
possible additional parameters. The Database MUST ignore all 


parameters it does not understand. 


5.5. DeviceOwner 


DeviceOwner contains information on device ownership that is provided 


as part of device registration. Some rulesets may require additional 
parameters. 

HO + 

|DeviceOwner | 

4+------------------ +---------- + 

|owner:vcard | REQUIRED | 

|operator:vcard | OPTIONAL | 

+------------------ +---------- + 
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Parameters: 


owner: The vCard contact information for the individual or business 
that owns the device is REQUIRED. 


operator: The vCard contact information for the device operator is 
OPTIONAL but may be required by specific rulesets. 


See PAWS Ruleset ID Registry (Section 9.1) for ruleset-specific 
requirements on mandatory vCard properties. Depending on the 
ruleset, the Database may be required to validate the device-owner 
information. In these cases, the Database MUST respond with an 
INVALID_VALUE error (see "Error Codes" (Section 5.17)) if validation 
fails. 


All contact information MUST be expressed using the structure defined 
by the "vCard Format Specification" [RFC6350], encoded in JSON 
[RFC7095]. Note that the vCard specification defines maximum lengths 
for each parameter. 


5.6.  RulesetInfo 


RulesetInfo contains parameters for the ruleset of a regulatory 
domain that is communicated using the Initialization (Section 4.3), 
Device Registration (Section 4.4), and Available Spectrum Query 
(Section 4.5) components. 


4-------------2--2--2---2------2--2---2-2---------- + 
|RulesetInfo | 
4------------------------------------------ + 
|authority:string REQUIRED 


|rulesetId:string | REQUIRED 
|maxLocationChange:float | see description | 
maxPollingSecs:int | see description 


| *other:any | OPTIONAL | 
+------------------------ +----------------- + 


Parameters: 
authority: A string that indicates the regulatory domain to which 


the ruleset applies is REQUIRED. It will normally be a 2-letter 
country code defined by Country Codes - ISO 3166 [ISO3166-1]. 
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rulesetId: The ID of a ruleset for the specified authority (see 
Ruleset ID Registry (Section 9.1)). The device can use this to 
determine additional device behavior required by the associated 
ruleset. To define new ruleset IDs, see "Defining Ruleset 
Identifiers" (Section 8.1). 


maxLocationChange: The maximum location change in meters is REQUIRED 
for the Initialization Response (Section 4.3.2), but OPTIONAL 
otherwise. Some regulatory domains mandate that, when the device 
changes location by more than this specified distance, it contact 
the Database to get the available spectrum for the new location. 
If this value is provided by the Database within the context of an 
Available Spectrum Response (Section 4.5.2), it takes precedence 
over the value within the Initialization Response (Section 4.3.2). 


maxPollingSecs: The maximum duration, in seconds, between requests 
for available spectrum is REQUIRED for the Initialization Response 
(Section 4.3.2), but OPTIONAL otherwise. The device MUST contact 
the Database to get available spectrum no less frequently than 
this duration. If this value is provided within the context of an 
Available Spectrum Response (Section 4.5.2), it takes precedence 
over the value within the Initialization Response (Section 4.3.2). 


other: Depending on the ruleset, other parameters may be required. 
The device MUST ignore all parameters in the message it does not 
understand. Consult the PAWS Parameters Registry (Section 9.2) 
for possible additional parameters. 


5.7. DbUpdateSpec 


This element is provided by the Database to notify devices of an 
upcoming change to the database URI. 


4+------------------------------- + 

| DbUpdateSpec | 

4+--------------------- +--------- + 4+-------------------------- + 

|databases:list |REQUIRED |------ >|DatabaseSpec 

4+—--------------------- +--------- + 1..* 4--------------- +---------- + 
|name:string | REQUIRED | 
juri:string | REQUIRED | 
4+—--------------- +---------- + 

Parameters: 

databases: List of one or more DatabaseSpec (Section 5.8) entries. 


A device needs to update its preconfigured entry for the 
responding Database with the alternate Databases listed in the 
DbUpdateSpec. 
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5.8. DatabaseSpec 


This element contains the name and URI of a Database. 


$ + 
|DatabaseSpec | 

+--------------- Ho ooo + 

name: string | REQUIRED | 

juri:string | REQUIRED | 

+--------------- 4---------- + 

Parameters: 

name: The display name. Its maximum length is 64 octets. 

uri: The corresponding URI of the Database. Its maximum length is 


1024 octets. 


5.9. SpectrumSpec 


The SpectrumSpec element encapsulates the schedule of available 
spectrum for a ruleset. 


4+--------------------------------------- + 
| Spect rumSpec | 
4R---------------------------- 4---------- + 
| ruleset Info:RulesetInfo | REQUIRED | 
spectrumSchedules:list REQUIRED |----- + 
timeRange:EventTime OPTIONAL | 
| frequencyRanges: list | OPTIONAL | 
|needsSpectrumReport:boolean | OPTIONAL | | 
|maxTotalBwHz:float | OPTIONAL | 
|maxContiguousBwHz: float | OPTIONAL | | 
4---------------------------- 4---------- + | 
Tm 
V 
$ + 
| SpectrumSchedule | 
+-------------------- +---------- + 
eventTime:EventTime REQUIRED 
spectra:list REQUIRED 
+-------------------- +---------- + 
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Parameters: 


rulesetInfo:  RulesetInfo (Section 5.6) is REQUIRED to identify the 


regulatory domain and ruleset to which the spectrum schedule 
applies (see Ruleset ID Registry (Section 9.1)). The device needs 
to use the corresponding ruleset to interpret the response. 

Values provided within rulesetInfo, such as maxLocationChange, 
take precedence over the values provided by the Initialization 
Procedure (Section 4.3). 


spectrumSchedules: The SpectrumSchedule (Section 5.10) list is 


REQUIRED. At least one schedule MUST be included. More than one 
schedule MAY be included to represent future changes to the 
available spectrum. How far in advance a schedule may be provided 
depends on the ruleset. If more than one schedule is included, 
the eventTime intervals MUST be disjoint and MUST be sorted in 
increasing time. A gap in the time schedule indicates no 
available spectrum during that time-interval gap. 


timeRange: The time range for which the specification is 


comprehensive is OPTIONAL. When specified, any gaps in time 
intervals within the spectrumSchedules element that overlap with 
the range specified by "timeRange" are interpreted by the device 
as time intervals in which there is no available spectrum. 


frequencyRanges: Specifying the frequency ranges for which the 


specification is comprehensive is OPTIONAL. It is a list of 
disjoint FrequencyRange (Section 5.13) entries. When specified, 
it typically corresponds to the frequency ranges governed by the 
ruleset, e.g., for TV white space, the frequency ranges can 
correspond to the VHF and UHF bands of the associated regulatory 
domain. A device can combine this information with the available- 
spectrum specification within the spectrumSchedules element to 
distinguish between "unavailable spectrum" and "spectrum for which 
no information has been provided". 


needsSpectrumReport: The Database MAY return true for this parameter 


Chen, 


if spectrumSchedules list is non-empty; otherwise, the Database 
MAY omit this parameter altogether, in which case, the default 
value is false. If this parameter is present and its value is 
true, the device sends a SPECTRUM_USE_NOTIFY (Section 4.5.5) 
message to the Database; otherwise, the device SHOULD NOT send the 
SPECTRUM_USE_NOTIFY message. Some rulesets mandate this value be 
set to true. 
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maxTotalBwHz: The Database MAY return a constraint on the maximum 
total bandwidth (in hertz) allowed, which may or may not be 
contiguous. Some rulesets mandate the Database to return this 


parameter. When present in the response, the device needs to 
apply this constraint to its spectrum-selection logic to ensure 
total bandwidth does not exceed this value. 


maxContiguousBwHz: The Database MAY return a constraint on the 
maximum contiguous bandwidth (in hertz) allowed. Some rulesets 
mandate the Database to return this parameter. When present in 
the response, the device needs to apply this constraint to its 
Spectrum-selection logic to ensure no single block of spectrum has 
bandwidth that exceeds this value. 


5.10. SpectrumSchedule 
The SpectrumSchedule element combines EventTime (Section 5.14) with 


Spectrum (Section 5.11) to define a time period in which the spectrum 
is valid. 


4------------------------------- + 

| SpectrumSchedule | 

4+-------------------- 4+---------- + 

|eventTime:EventTime | REQUIRED | +-------------------- + 

|spectra:list | REQUIRED |------- >|Spectrum | 

4+-------------------- 4+---------- + 0..* +-------------------- + 
| resolutionBwHz: float | 
|profiles:list | 
4R-------------------- + 

Parameters: 


eventTime: The EventTime (Section 5.14) is REQUIRED to express 
"when" this specification is valid. 


spectra: The Spectrum (Section 5.11) list is REQUIRED to specify the 
available spectrum and permissible power levels, one per 
resolutionBwHz. The list MAY be empty when there is no available 
spectrum. 


5.11. Spectrum 


Available spectrum can be characterized by an ordered list of 
spectrum profiles that defines permissible power levels over a set of 
frequency ranges. Each Spectrum element defines permissible power 
levels as maximum power spectral densities over a specified 
resolution bandwidth, "resolutionBwHz". Note that the spectrum 
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profiles represent the "availability mask", as defined by the 
governing ruleset; they are not intended to encode device-level 
transmission-mask requirements. 


NOTE: Within the contexts of the AVAIL SPECTRUM RESP (Section 4.5.2), 
AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4), and SPECTRUM_USE_NOTIFY 
(Section 4.5.5) messages, the power levels expressed within the 
Spectrum messages refer to EIRP. Future extensions of PAWS may use 
Spectrum in other contexts for other definitions of power levels. 


o To support a ruleset that defines different "wide-band" and 
"narrow-band" power levels, PAWS allows multiple Spectrum elements 
to be included in the available-spectrum response, each with a 
different resolution bandwidth. 


o When multiple Spectrum elements are included in the response, each 
represents a constraint that the device must satisfy (logical 
AND). 


o Each Spectrum element covers the range of frequencies governed by 
a ruleset, rather than splitting the frequencies across multiple 
Spectrum elements for the same resolution bandwidth. 


o Each spectrum profile represents the maximum permissible power 
spectral density over a contiguous range of frequencies. 


o When multiple spectrum profiles are included, they MUST be 
disjoint and MUST be ordered in non-decreasing frequency value. 


o Gaps in frequencies between consecutive spectrum profiles 
represent unavailability for those frequencies. 


The following figure illustrates the Spectrum element and the 
SpectrumProfile list. 
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|Spectrum | 
4R--------------------- 4R--------- * 
[resolutionBwHz:float |REQUIRED | 
|profiles:list |REQUIRED |---+ 


|hz:float |REQUIRED | 
| dbm: float |REQUIRED | 
4R---------------- 4R--------- + 


Parameters: 


resolutionBwHz: This parameter defines the resolution bandwidth (in 
hertz) over which permissible power spectral density is defined. 
For example, FCC regulation would require one spectrum 
specification at a bandwidth of 6 MHz, and ETSI regulation would 
require two specifications, at 0.1 MHz and 8 MHz. 


profiles: A SpectrumProfile (Section 5.12) list specifies 


permissible power levels over a set of frequency ranges. The list 
MAY be empty if there is no available spectrum. 


Chen, et al. Standards Track [Page 46] 


RFC 7545 PAWS May 2015 


The following example shows permitted power spectral densities fora 
single resolution bandwidth of 6 MHz (for illustrative purposes 
only): 


[ 


"resolutionBwHz": 6e6, 
"profiles": [ 
[ 
Pazo 9. 1888, "aba" 30.0); 
("hz": 5.30e8, "dom": 30.0) 
l; 


] 
This is interpreted as: 


o Over any 6 MHz within the frequency range [518 MHz, 530 MHz), 
maximum permitted power is 30.0 dBm (1000 mW) 


Consider now an example with two different sets of permitted power 
spectral densities for the same set of frequencies over different 
resolution bandwidths (for illustrative purposes only): 


"resolutionBwHz": 6e6, 
"profiles": [ 
[ 
["hz": 5,1868, "dbm"i 304.07], 
("hz": 5.30e8, "dom": 30.0) 
l, 


] 
), 
{ 


"resolutionBwHz": le5, 
"profiles": [ 
[ 
("hz": 5.18e8, "dom": 27.0}, 
("hz": 5.30e8, "dom": 27.0) 
l, 
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This is interpreted as: 


o Over any 6 MHz within the frequency range [518 MHz, 530 MHz), 
maximum permitted power is 30.0 dBm (1000 mW), and 


o Over any 100 kHz within the frequency range [518 MHz, 530 MHz), 
maximum permitted power is 27.0 dBm (500 mW) 


This would allow, for example, operating two 100 kHz sub-channels 
within the indicated 12 MHz range at 500 mW each, totaling 1000 mW. 
Of course, many combinations are possible, as long as they satisfy 
both conditions. 
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The following example encodes multiple 
having a gap from 530 MHz to 536 MHz 


only): 
[ 


"resolutionBwHz": 
"profiles": [ 
[ 
("hz" : 
["hz" : 
["hz" : 
["hz" : 
l, 
[ 


.18e8, 
.24e8, 
.24e8, 
.30e8, 


aaa uo 


("hz": 5.3668, 
("hz": 5.42e8, 
l; 


] 
), 
{ 


"resolutionBwHz": 
"profiles": [ 


[ 


{"hz": 5.18e8, 
("hz": 5.2468, 
{"hz": 5.2468, 
("hz": 5.30e8, 

l; 

[ 
("hz": 5.36e8, 
("hz": 5.42e8, 

l; 

] 
} 
] 
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5.12. SpectrumProfile 
A spectrum profile is characterized by an ordered list of (frequency, 
power) points that represents the shape of maximum permissible power 
levels over a range of frequencies as a piecewise linear curve. 


o It MUST contain a minimum of two entries. 


o The entries in the list MUST be ordered in non-decreasing 
frequency values. 


o Two consecutive points MAY have the same frequency value to 
represent a "step function". 


o Three or more points MUST NOT share the same frequency value. 
o The first frequency is inclusive; the last frequency is exclusive. 


NOTE: This encoding allows presentation of "ramps" where the slope of 
a line segment may be finite and non-zero. 


The following figure illustrates the SpectrumProfile element. 


4------------------------------- + 
|SpectrumProfile | 
4--------------------- 4--------- + 
|list |REQUIRED |---+ 

4--------------------- 4--------- + | 2..* 
V 

4----------------2---------- + 

|SpectrumProfilePoint | 

4---------------- 4--------- + 

|hz:float |REQUIRED | 

| dom: float | REQUIRED | 

4---------------- 4+--------- + 


Parameters of each point in the profile: 
hz: The frequency, in hertz, at which the power level is defined. 
dbm: The power level, expressed as dBm per resolution bandwidth, as 


defined by the resolutionBwHz element of the enclosing Spectrum 
(Section 5.11) element. 
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5.13. FrequencyRange 


FrequencyRange specifies a frequency range. 


+-------------------------------- + 

| FrequencyRange | 

+---------------------- +--------- + 

|startHz:float |REQUIRED | 

| stopHz:float |REQUIRED | 

+---------------------- +--------- + 

Parameters: 

startHz: The inclusive start of the frequency range (in hertz) is 
REQUIRED. 

stopHz: The exclusive end of the frequency range (in hertz) is 
REQUIRED. 


5.14.  EventTime 


The EventTime element specifies the start and stop times of an 
"event". This is used to indicate the time period for which a 
Spectrum (Section 5.11) is valid. 


| Event Time | 
4R--—--------------- Ho + 
|startTime:string |REQUIRED | 
[stopTime:string |REQUIRED | 
4R-----------2------ 4R--------- * 


Parameters: 

startTime: The inclusive start of the event is REQUIRED. 

stopTime: The exclusive end of the event is REQUIRED. 

Both times are expressed using the format, YYYY-MM-DDThh:mm:ssZ, as 


defined by "Date and Time on the Internet: Timestamps" [RFC3339]. 
The times MUST be expressed using UTC. 


Chen, et al. Standards Track [Page 51] 


RFC 7545 PAWS May 2015 


A device that does not have access to the current date and time MUST 
use the timestamp at the top level of the response message as a 
substitute for the current time (see "Available Spectrum Response" 
(Section 4.5.2) and "Available Spectrum Batch Response" 


(Section 4.5.4)). For example, 
o (startTime - timestamp) gives the duration that a device must wait 
before the event becomes "active". If the value is zero or 


negative, the event is already active. 


o If the event is already active, (stopTime - timestamp) is the 
duration that the event remains active. If the value is zero or 
negative, the event is no longer active and MUST be ignored. 


5.15. GeoSpectrumSpec 


The GeoSpectrumSpec element encapsulates the available spectrum for a 
location. It is returned within an AVAIL_SPECTRUM_BATCH_RESP 
(Section 4.5.4) batch response that contains multiple GeoSpectrumSpec 
entries, each matching a location provided in the batch request. 


4+---------------------------------- + 
|GeoSpectrumSpec | 
4+----------------------- +---------- + 
|location:GeoLocation | REQUIRED | 
|spectrumSpecs:list | REQUIRED |------- + 
4----------------------- 4---------- + | 
| E 
V 
4R-------------- * 
| SpectrumSpec | 
4+-------------- + 


Parameters: 


location: The GeoLocation (Section 5.1) identifies the location at 
which the spectrum schedule applies. 


spectrumSpecs: The SpectrumSpec (Section 5.9) list is REQUIRED. At 
least one entry MUST be included. Each entry represents schedules 
of available spectrum for a ruleset. More than one entry MAY be 
included to support multiple rulesets at a location. 
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5.16. DeviceValidity 


The DeviceValidity element is used to indicate whether a device is 
valid. See Section 4.6.2. 


4+-------------------------- = - == + 
|DeviceValidity | 
4+---------------------------- +---------- + 
deviceDesc:DeviceDescriptor REQUIRED 

isValid:boolean REQUIRED 

[reason:string | OPTIONAL | 
p------------------2---------- p---------- t 
Parameters: 
deviceDesc: The DeviceDescriptor (Section 5.2) that was used to 


check for validity is REQUIRED. 


isValid: This is a REQUIRED boolean value that indicates whether the 
device is valid. 


reason: If the device identifier is not valid, the Database MAY 
include a reason. The reason MAY be in any language. Its maximum 
length is 128 octets. 
Ou f. Error Element 


If the Database responds to a PAWS request message with an error, it 
MUST include an Error element. 


Sass SS 2 + 29 22 SR ees a ecc + 
|Error 
$2 shensisssngs 4----------------- t 
code:int REQUIRED 
message:string OPTIONAL 
|data:any | see description | 
===> === 2>= 4----------------- t 
Parameters: 


code: An integer code that indicates the error type is REQUIRED. 
Values MUST be within the range -32768 to 32767, inclusive. 


message: A description of the error is OPTIONAL. It MAY be in any 
language. Its maximum length is 128 octets. 
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data: The Database MAY include additional data. For some errors, 
additional data may be required (see Table 1). The device MUST 
ignore any data parameters it does not understand. 


The following table lists predefined and reserved error codes. They 
are loosely grouped into the following categories: 


-100s: Indicates compatibility issues, e.g., version mismatch, 
unsupported or unimplemented features. 


-200s: Indicates that the device request contains an error that 
needs to be modified before making another request. 


-300s: Indicates authorization-related issues. 
Values that are not defined explicitly in the Error Codes 


Table (Table 1) below are unassigned. To define new error codes, see 
PAWS Error Code Registry (Section 9.3). 


Code Name Description and Additional Parameters 

0 (reserved) 

-100 (reserved) 

-101 VERSION The Database does not support the specified 
version of the message. This error does not 
use any additional data. 

-102 UNSUPPORTED The Database does not support the device. 


For example, it supports none of the rulesets 
Specified in the request or does not support 

the device, based on its device type, model, 

etc. This error does not use any additional 

data. 

-103 UNIMPLEMENTED The Database does not implement the optional 
request or optional feature. This error does 
not use any additional data. 

-104 OUTSIDE COVERAGE The specified geolocation is outside the 
coverage area of the Database. The Database 
MAY include a DbUpdateSpec (Section 5.7) to 
provide a list of alternate Databases that 
might be appropriate for the requested 
location. See OUTSIDE COVERAGE Error 
(Section 5.17.1) for more details. 
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-105 DATABASE CHANGE The Database has changed its URI. The 
Database MAY include a DbUpdateSpec (Section 
5.7) in the error response to provide devices 
with one or more alternate database URIs. 
The device needs to update its preconfigured 
entry for the responding Database with the 
alternate Databases listed in the 
DbUpdateSpec. See DATABASE CHANGE Error 
(Section 5.17.2) for more details. 

-200 (reserved) 

-201 MISSING A required parameter is missing. The 
Database MUST include a list of the required 
parameter names. The Database MAY include 
only names of parameters that are missing, 
but MAY include a full list. Including the 
full list of missing parameters may reduce 
the number of re-queries from the device. 
See MISSING Error (Section 5.17.3) for more 
details. 

-202 INVALID VALUE A parameter value is invalid in some way. 
The Database SHOULD include a message 
indicating which parameter and why its value 
is invalid. This error does not use any 
additional data. 

-300 (reserved) 

-301 UNAUTHORIZED The device is not authorized to used the 
Database. Authorization may be determined 
by the ruleset or be dependent on prior 
arrangement between the device and Database. 
This error does not use any additional data. 

-302 NOT REGISTERED Device registration required, but the device 
is not registered. This error does not use 
any additional data. 

-32000 (reserved) Reserved for JSON-RPC error codes. 

to 

-32768 


Table 1: Error Codes 
Dd vds OUTSIDE COVERAGE Error 
When the error code is OUTSIDE COVERAGE, the Database MAY include an 
ErrorData element within its Error response as the "data" parameter, 
and, if present, the ErrorData contains a DbUpdateSpec (Section 5.7) 


element that provides a list of alternate Databases that might be 
appropriate for the requested location. 
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+--------------------------- + 

|Error | 

+---------------- +---------- + 

|code:int | REQUIRED | 

|message:string | OPTIONAL | a T + 

|data:ErrorData | OPTIONAL |--->|ErrorData 

4£---------------- 4---------- + +------------------ +---------- + 
|spec:DbUpdateSpec | OPTIONAL | 
+------------------ +---------- + 


5.17.2. DATABASE_CHANGE Error 


When the error code is DATABASE CHANGE, the Database MAY include an 
ErrorData element within its Error response as the "data" parameter, 
and, if present, the ErrorData contains a DbUpdateSpec (Section 5.7) 
element that provides a list of alternate Databases. 


+--------------------------- + 

|Error | 

+---------------- +---------- + 

|code:int | REQUIRED | 

message:string OPTIONAL A E + 

data:ErrorData OPTIONAL |--->|ErrorData | 

+---------------- +---------- + +------------------ +---------- + 
|spec:DbUpdateSpec | REQUIRED | 
+------------------ +---------- + 


5.17.3. MISSING Error 


When the error code is MISSING, the Database MUST include an 
ErrorData element within its Error response as the "data" parameter, 
and the ErrorData element MUST include a list of the missing required 
parameters and MAY include the list of all required parameters. 


+--------------------------- + 

|Error | 

+---------------- +---------- + 

|code:int | REQUIRED | 

|message:string | OPTIONAL | 5 a a E + 

|data:ErrorData | REQUIRED |--->|ErrorData 

4£---------------- 4---------- + +---------------- +---------- + 1..* 
|parameters:list | REQUIRED |--+ 
4---------------- 4---------- + | 

v 
string 
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Parameters: 


parameters: List of one or more parameter names (strings). The name 
of a parameter is expressed using dotted notation, when 
appropriate, e.g., "deviceDesc.serialNumber". 


6. Message Encoding 


PAWS is encoded using JSON-RPC [JSON-RPC] (see also "The JavaScript 
Object Notation (JSON) Data Interchange Format" [RFC7159]). Each 
component described in Protocol Functionalities (Section 4) 
corresponds to one or more JSON-RPC methods. This section discusses 
how to encode the data models presented in Sections 4 and 5 into JSON 
and provides some example encodings. The JSON examples may contain 
ellipses (...) to represent additional properties or elements that 
have been omitted in order to make the examples more concise. 


6.1. JSON-RPC Binding 


The JSON-RPC [JSON-RPC] protocol consists of two basic objects, 
Request and Response: 


o The JSON-RPC Request object encapsulates a PAWS functionality 
(operation) and the request message. 


o The JSON-RPC Response object encapsulates a PAWS response message 
and an Error element. 


The Database and device MUST support JSON-RPC 2.0 encoding, with the 
restriction that the "id" parameter in the messages MUST be a string. 
The device should generate the "id" uniquely enough to allow the use 
of JSON-RPC batch. 


The JSON-RPC Request for PAWS has the following form: 


{ 


"jsonrpc": "2.0", 

"method": "spectrum.paws.methodName", 
"params": «PAWS REQ», 

"id: "idStrrng" 


} 


where "method" is the name of a PAWS functionality (operation), and 
<PAWS_REQ> represents one of the PAWS request messages associated 
with the method (see Sections 4.3 through 4.6). Method names are 
defined with the prefix "spectrum.paws.". 


Chen, et al. Standards Track [Page 57] 


RFC 7545 PAWS May 2015 


The non-error JSON-RPC Response for PAWS has the following form: 


{ 


"jsonrpc": "2.0", 
"result": <PAWS_RESP>, 
"id": "idString" 


} 


where <PAWS_RESP> represents one of the PAWS response messages 
associated with the method, and "id" is copied from the request. 


The error JSON-RPC Response for PAWS has the following form: 


{ 
"jsonrpe": "2.0", 
TEF Or YTE d 
"code": -102, 
"message": "An appropriate error message.", 
"datas {> stay} 
), 
"id": -"idString" 
} 


where the "error" object corresponds to the Error Element 

(Section 5.17), and "code" is an error code described in the same 
section. The Database SHOULD attempt to use the most specific 
applicable PAWS error code. When an accurate one is not available, 
it SHOULD fall back to standard JSON-RPC error codes as defined in 
the JSON-RPC specification. For example, if the Database receives 
invalid JSON from the device, it should respond with "-32700", 
Signifying a parse error. As a last resort, the Database MAY send a 
suitable HTTP 5xx response. 
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6.1.1. Method Names 


Table 2 defines the method name, request object, and response object 
for each functionality defined in Protocol Functionalities 
(Section 4). 


hes = Sea Ha SS Se ee a ee eS E Se ee See eS Sear eee + 
| Method Name | 
Request 
Response 
SE i aa cm Tus num an cma cna a a a 2979859523525 mR cs =8% + 


spectrum.paws.init 
INIT_REQ (Section 4.3.1) 
INIT_RESP (Section 4.3.2) 


spectrum.paws.register 
REGISTRATION_REQ (Section 4.4.1) 
REGISTRATION_RESP (Section 4.4.2) 


| 

| 

| 

| 

| 

| spectrum. paws .getSpectrum 

| AVAIL_SPECTRUM_REQ (Section 4.5.1) 
| AVAIL_SPECTRUM_RESP (Section 4.5.2) 
| 

| 

| 

| 

| 

| 

| 

| 


spectrum.paws.getSpectrumBatch 
AVAIL_SPECTRUM_BATCH_REQ (Section 4.5.3) 
AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4) 


spectrum.paws.notifySpectrumUse 
SPECTRUM_USE_NOTIFY (Section 4.5.5) 
SPECTRUM_USE_RESP (Section 4.5.6) 


spectrum.paws.verifyDevice 
DEV_VALID_REQ (Section 4.6.1) 
DEV_VALID_RESP (Section 4.6.2) 


Table 2: Method Names 
6.1.2. JSON Encoding of Data Models 


JSON [RFC7159] encoding of the data models described in Sections 4 
and 5 is straightforward: 


o Each data model describes the contents of a JSON object. 
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Each parameter of a data model corresponds to a member of the 
corresponding JSON object: 


* The parameter name of the data model is the same as the member 
name of the JSON object. 


* The parameter data type describes the type of the member value. 


Primitive types map to JSON type, as described in Section 4 and 
repeated here: 


string: A JSON string, restricted to UTF-8 encoding 

int: A JSON number, without a fractional or exponent part 
float: A JSON number 

boolean: One of the JSON values, true or false 


The list type maps to a JSON array, except that all values in the 
array are of the same type. 


When the parameter data type refers to another data model, that 
data model describes a nested JSON object. 


The encoded JSON object for each of the Request and Response 
message listed in the Method Names Table (Table 2) also includes 
the following members: 


type: The name of the message, e.g., "INIT REQ" 


version: The PAWS version, e.g., "1.0" 


See the following sections for examples. 


Chen, 
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6.2. Example Encoding: spectrum.paws.init Method 


An example of the "spectrum.paws.init" JSON-RPC request is shown 


below. 
{ 
"jsonrpo"*: "2.0", 
"method": "spectrum.paws.init", 
"params": { 
"type": "INIT REQ", 
"version": "1.0", 
"deviceDesc": { 
"serialNumber": "XXX", 
"fccId": "YYY", 


"rulesetIds": ["FccTvBandWhiteSpace-2010"] 
), 
"location": ( 
"point": { 
"center": {"latitude": 37.0, "longitude": -101.3) 
} 
} 
- 
"id": "xxxxxx" 


} 


An example of the corresponding JSON-RPC response is shown below. 


{ 


"jsonrpc": "2.0", 
"result": { 
"type": "INIT RESP", 
"version": "1.0", 
"rulesetInfos": [ 
( 
"authority": "us", 
"rulesetId": "FccTvBandWhiteSpace-2010", 
"maxLocationChange": 100, 
"maxPollingSecs": 86400 
} 
] 
- 
"id": "xxxxxx" 


} 
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6.3. 


Example Encoding: spectrum.paws.getSpectrum Method 


An example of the "spectrum.paws.getSpectrum" JSON-RPC request is 
shown below: 


{ 


} 


"jsonrpco": "2.0"; 
"method": "spectrum.paws.getSpectrum", 
"params": { 
"type": "AVAIL SPECTRUM REQ", 
"version": "1.0", 
"deviceDesc": ( 
"serialNumber": "XXX", 
"fccId": "YYY", 
"rulesetlds": ["FccTvBandWhiteSpace-2010"] 
, 
"location": { 
"point": ( 
"center": ("latitude": 37.0, "longitude": -101.3) 
) 
- 
"antenna": {"height": 10.2, "heightType": "AGL"] 
), 


"id": "xxxxxx" 


The following example "spectrum.paws.getSpectrum" JSON-RPC response 


contains: 
o A schedule with two time ranges 
O A spectrum profile for one resolution bandwidth (6 MHz) 
o The power levels for two frequency segments: 
* From 518 MHz to 542 MHz 
* From 620 MHz to 626 MHz 
o In practice, each "profiles" list contains (frequency, power) 


points to cover all frequencies governed by the associated 
ruleset. See "Spectrum" (Section 5.11) for a more detailed 
discussion on the representation. 
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{ 
"jsonrpc": 
"result": { 
"type " : 
"version": 
"timestamp": 
"deviceDesc": { 
"serialNumber": 
"tecla MY YY"; 
"rulesetlds": [" 
), 
"spectrumSpecs": 
{ 
"rulesetInfo": 
"authority": 
"rulesetId": 


"o Qt 


TL01; 


), 


"needsSpectrumReport": 


PAWS 


"AVAIL SPECTRUM RESP", 


"2013-03-02T14:30:212", 


"XXX", 
FccTvBandWhiteSpace-2010"] 
[ 

{ 

"us", 


"FccTvBandWhiteSpace-2010" 


false, 


"spectrumSchedules": [ 


( 

"eventTime": 
"startTime": 
"stopTime": 

- 

"spectra": [ 


{ 
"2013-03-02T14:30:212", 
"2013-03-02T20:00:002" 


{ 
"resolutionBwHz": 6e6, 
"profiles": [ 
[ 
("Az"5.18e8, "dbm"+305:.0), 
("hz":5.36e8, "dbm":30.0}, 
("hz":5.36868, "dbm"s36.0yF, 
("hz":5.42e8, "dbm":36.0) 
l]; 
[ 
("hz":6.20e8, "dbm":30.0}, 
{"hz":6.26e8, "dbm":30.0} 


l; 


] 
}, 
{ 


"eventTime": 
"startTime": 
"stopTime": 
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{ 
"2013-03-02T22:00:002", 
"2013-03-03T14:30:212" 
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), 
"spectra": [ 


), 


"id": "xxxxxx" 


} 
The following example "spectrum.paws.getSpectrum" JSON-RPC response 
includes a spectrum profile that contains specifications for two 


different bandwidth resolutions (6 MHz and 100 kHz): 


{ 


"jsonrpco'*: "23707; 
"result": { 
"Lype": "AVAIL SPECTRUM RESP", 
"version": "1.0", 
"timestamp": "2013-03-02T14:30:212", 
"deviceDesc": { 
"serialNumber": "XXX", 
}, 
"spectrumSpecs": [ 
{ 
"rulesetInfo": { 
"authority": "xx", 
}, 
"needsSpectrumReport": false, 
"spectrumSchedules": [ 
{ 
"eventTime": { 
"startTime": "2013-03-02T14:30:212", 


"stopTime": "2013-03-02T20:00:002" 
), 


"spectra": [ 
( 
"resolutionBwHz": 6e6, 
"profiles": [ 


[ 

("hz":5.18e8, "dbm":30.0], 
("hz":5.36e8, "dbm":30.0], 
("hz":5.36e8, "dbm":36.0], 
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("hz":5.42e8, 

l, 

[ 
{"hz":6.20e8, 
{"hz":6.26e8, 

l, 

] 

), 

{ 
"resolutionBwHz": 
"profiles": [ 

[ 
("hz":5.18e8, 
("hz":5.36e8, 
("hz":5.36e8, 
("hz":5.42e8, 

l, 

[ 
{"hz":6.20e8, 
{"hz":6.26e8, 

l, 

] 

} 

] 

- 
{ 

"eventTime": { 
"startTime": 
"stopTime": 

), 

"spectra": [ 

] 

} 
] 
} 
] 
- 
"id": "xxxxxx" 
} 
Chen, et al. 
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:36.0) 


:30.0), 
:30.0) 
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227.0}, 
30.0}, 
30.0} 


0}, 


27.0}, 
227.0} 
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6.4. Example Encoding: DeviceOwner vCard 


The DeviceOwner (Section 5.5) data model contains member values that 
are JSON encodings of vCard, as described in "jCard: The JSON format 
for vCard" [RFC7095]. An example fragment is provided below: 


"deviceOwner": { 
"owner": [ 
"vcard", [ 
["version", {}, "text", "4.0"], 
["kind", {}, "text", "org"] P 
["fn", {}, "text", "Racafrax, Inc.™] 
] 
l, 
"operator": [ 
"vcard", [ 
["version", {}, "text", "4.0"], 
["fn", {}, "text", "John Frax"], 
"ade", Is "text", 
pen, "",."100 Main Street", 
"Summersville", "CA", "90034", "USA" 
] 
l; 
["tel", ds "uri", "teli£1-213-555—1212^"], 
["email", {}, "text", "j.frax@rackafrax.com"] 


} 
7. HTTPS Binding 


This section describes the use of "HTTP Over TLS" [RFC2818] (HTTPS) 
as the transfer mechanism for PAWS. TLS provides message integrity 
and confidentiality between the Master Device and the Database, but 
only when best current practices are adopted, including use of 
recommended cipher suites and modes of operation. Consequently, to 
improve PAWS security and interoperability, implementations of the 
Database and Master Device MUST follow best current practices defined 
by "Recommendations for Secure Use of Transport Layer Security (TLS) 
and Datagram Transport Layer Security (DTLS)" [RFC7525]. 


Depending on a prior relationship between a Database and device, the 


server MAY require client authentication, as described in the 
"Transport Layer Security (TLS) Protocol" [RFC5246], to authenticate 
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the device. When client authentication is required, the Database 
MUST specify, by prior arrangement, acceptable root Certification 
Authorities (CAs) to serve as trust anchors for device certificates. 


To enable Databases to handle large numbers of requests from large 
numbers of devices, the Database MAY support and devices SHOULD 
support "Stateless TLS Session Resumption" [RFC5077]. 


A PAWS request message is carried in the body of an HTTP POST 
request. A PAWS response message is carried in the body of an HTTP 
response. A PAWS response SHOULD include a Content-Length header. 


The POST method is the only method REQUIRED for PAWS. If a Database 
chooses to support GET, it MUST be an escaped URI, but the encoding 
of the URI is outside the scope of this document. The Database MAY 
refuse to support the GET request by returning an HTTP error code, 
such as 405 (method not allowed). 


The Database MAY redirect a PAWS request by returning a HTTP 3xx 
response (as defined by Section 6.4 of "HTTP/1.1: Semantics and 
Content" [RFC7231]). The Database MUST provide the redirect URI in 
the Location header of the 3xx response, and the device MUST handle 
redirects by using the Location header provided by the Database. 
When redirecting, the device MUST observe the delay indicated by the 
Retry-After header. The device MUST authenticate the Database that 
returns the redirect response before following the redirect. Also, 
the device MUST authenticate the Database indicated in the redirect. 
Since the device may communicate with a Database (which it 
authenticated) without user interaction, when the response code is 
301 (Moved Permanently), the device MAY redirect without asking a 
user for confirmation, even thought it is in response to an HTTP POST 
method. 


The Database SHOULD use HTTP status code "307 Temporary Redirect" to 
indicate that the device SHOULD resubmit the same request to an 
alternate URI. The device MAY revert to the original URI for the 
very next request, or it MAY continue to use the alternate URI for a 
period of time, e.g.,: 


o For the remainder of its session, or 
o For a fixed period of time, or 

o Until power cycled, or 

o Until it receives another redirect 


However, the device does not need to modify its stored list of URIs. 
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For a minimum of two weeks before the URI of the Database changes 
permanently, it MUST use the database-change (DbUpdateSpec 

(Section 5.7)) mechanism to notify devices, as described in 
"Configuration Update: Database URI Changes" (Section 4.1.2). After 
the Database has moved, requests to the original URI MAY return HTTP 
status code 301 (Moved Permanently) to indicate that the device 
SHOULD resubmit the request, and all future requests, to the 
indicated alternate URI. 


8. Extensibility 


This section describes procedures for extending PAWS. No extensions 
should be made that would return sensitive device-specific 
information in database responses. 


8.1. Defining Ruleset Identifiers 


A ruleset represents a set of device-side requirements for which the 
device has been certified. It typically corresponds to, but is not 
limited to, a set of rules that govern a specific set of radio 
spectrum for a regulatory domain. 


Ruleset identifiers are defined and registered in the Ruleset ID 
Registry following the procedure in Section 9.1. Ruleset ID values 
MUST conform to the ruleset-id ABNF. If the Ruleset ID requires 
additional parameters, they are registered in the PAWS Parameters 
Registry, as described by Section 9.2. The ABNF syntax [RFC5234] is 
as follows. 


ruleset-id = 1*64ruleset-char 
ruleset-char ALPHA / DIGIT AM Jo mT 


When defining a Ruleset ID: 

o It can be useful for the identifier to be descriptive of the set 
of rules that allow a device to operate within one or more 
regulatory domains. For example, it might include the name of a 
regulatory body or a certification process. 


o The identifier SHOULD include some sort of version information, 
such as a year and/or version number. 


o The maximum length of the identifier is 64 octets. 
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8224 


8:3. 


Che 


Defining New Message Parameters 


New request or response parameters for use with PAWS are defined and 
registered in the parameters registry following the procedure in 
Section 9.2. 


Parameter names MUST conform to the param-name ABNF, and parameter 
values syntax MUST be well-defined (e.g., using ABNF or a reference 
to the syntax of an existing parameter). 


param-name = 1*64name-char 
name-char = ALPHA / DIGIT / " " 
Parameter names use lowerCamelCase by convention. The maximum length 


of a name is 64 octets. 


Unregistered vendor-specific parameter extensions that are not 
commonly applicable and are specific to the implementation details of 
the Database where they are used SHOULD use a vendor-specific prefix 
that is not likely to conflict with other registered values (e.g., 
begin with 'companyname'). 


Defining Additional Error Codes 


Additional error codes can be registered to extend the set listed in 
Section 5.17, following the procedures in Section 9.3. If the error 
code requires additional response parameters, they are registered in 
the PAWS Parameters Registry, as described by Section 9.2. 


By convention, the error code is a negative integer value, using one 
of the range of values defined in Error Codes (Section 5.17). If an 
appropriate category does not exist, a value from a different range 

may be used. 


IANA Considerations 


There are three registries associated with PAWS: 


o PAWS Ruleset ID Registry (Section 9.1) 

o PAWS Parameter Registry (Section 9.2) 

o PAWS Error Code Registry (Section 9.3) 

All registries use the Specification Required policy [RFC5226], with 
a Designated Expert appointed by the IESG. Specific criteria that 


the Designated Expert should use in assessing registrations are given 
below in the description of each registry. The Designated Expert 
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should take advice from the community through the paws@ietf.org 
mailing list, and the registrant is encouraged to post to the mailing 
list before formally requesting the registration from IANA. The 
intention is that new registrations will be accompanied by a 
published specification. But in order to allow for the allocation of 
values prior to publication of the specification, the Designated 
Expert can approve allocations once it seems clear that the 
specification will be published. Upon approval, IANA will post the 
registrations that are not intended to be published in an RFC. 


9.1. PAWS Ruleset ID Registry 
This specification establishes the "PAWS Ruleset ID Registry". 


Ruleset type names for inclusion in PAWS messages are registered on 
the advice of one or more Designated Experts, with Specification 
Required [RFC5226]. The specification must include a reference to 
the regulatory domain to which it applies. To increase 
interoperability, it is more desirable to have fewer rulesets than to 
have many rulesets with small variations. Consequently, the 
Designated Expert should avoid duplication and should encourage the 
registrant to look for alternatives if there are only small 
variations from an existing ruleset. The Designated Expert should 
ensure that the proposed registration is complete with respect to its 
associated regulatory domain and may seek an expert familiar with 
those rules to participate in the review on the paws@ietf.org mailing 
list. 


The PAWS Ruleset ID Registry includes the following: ’Ruleset 
Identifier’, 'Reference', and ’Template’. The Template column will 
include links to the registration templates, either posted by IANA or 
linked to the relevant sections of RFCs. 


9.1.1. Registration Template 


Ruleset identifier: The name of the ruleset. See Section 8.1 of RFC 
7545 for the format requirements of this identifier. 


Specification document(s): Reference to the document that specifies 
the parameter, preferably including a URI that can be used to 
retrieve a copy of the document. An indication of the relevant 
sections also may be included but is not required. 
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Additional Parameter Requirements: Listing of additional parameter 
requirements to associate with the ruleset. Note that new 
parameters are registered separately in the PAWS Parameters 
Registry, as described by Section 8.2. Two types of additional 
parameter requirements are: 


* Addition of new parameters to existing structures, or 
modification of the REQUIRED and OPTIONAL requirements for 
existing parameters. 


* Modification of requirements to existing parameter values. 

For adding new parameters or modifying requirements of existing 
parameters, the registration should include a table for each 
affected structure that lists the structure’s parameter changes. 
Each table should include a structure name in its heading and have 
the following columns: 

Parameter name: Name of the parameter added or modified. 


Type: Data type of the parameter value. 


Requirement: Whether the parameter is REQUIRED or OPTIONAL for 
the ruleset. 


Notes: Any additional notes that might be useful to implementors. 


For modifying requirements to existing parameter values, the 
registration should include a table for each affected structure 


that lists the structure’s parameter changes. Each table should 
include a structure name in its heading and have the following 
columns: 


Parameter name: Name of the parameter. 
Type: Data type of the parameter value. 


Additional requirements: Additional requirements on the parameter 
value. 


IANA will post each registration template that is not intended to be 
published in an RFC. 


Note that the Additional Parameter Requirements section can be quite 
extensive, so it will not appear directly in the IANA Ruleset ID 

Registry table. The table, however, will contain a link to the full 
registration template for easy access to the additional requirements. 
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9.1.2. Initial Registry Contents 


The PAWS Ruleset ID Registry enables protocol extensibility to 
support any regulatory domain and ruleset. The initial contents of 
the registry, however, include only FCC-specific and ETSI-specific 
entries, because, as of this writing, they are the only regulatory 
domains that have finalized rules. There is no intent to restrict 
the protocol to any particular set of authorities. 


The initial contents of the PAWS Ruleset ID Registry are listed 
below; each section corresponds to a single entry in the registry. 


9.1.2.1. Federal Communications Commission (FCC) 

For the additional parameters that start with the "fcc" prefix, see 

PAWS Parameters Registry Initial Contents (Section 9.2.2) for more 

information. 

Ruleset identifier:  FccTvBandWhiteSpace-2010 

Specification document(s): This ruleset refers to the FCC rules for 
TV-band white-space operations established in the Code of Federal 
Regulations (CFR), Title 47, Part 15, Subpart H [FCC-CFR47-15H]. 

Additional Parameter Requirements 

Each of the following tables defines additional parameters for the 

indicated PAWS message. Note that the Requirement column lists FCC, 


not PAWS, requirements/optionality rules. 


The FCC requires registration of "Fixed Devices". Additionally, 
deviceOwner is required in the registration request: 


Registration Request (Section 4.4.1) 


Fes ++ === +++ HS ETRE AS Fea el IS + 
| Parameter | Type | Requirement | Notes 
| Name | | | | 
a SS SSeS {faa SSS SSeS $ A == Sosa == 2 22 =% + 
deviceOwner DeviceOwner REQUIRED For registering 
(Section 5.5) Fixed Devices 
do a SS a $ $2 O + 
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Available Spectrum Request (Section 4.5.1) 
$ AZ e E ER $2 += + 
| Parameter | Type | Requirement | Notes | 

| Name | | | 
$ AZ EE AT EAE N $ Ho + 
| deviceDesc | DeviceDescriptor (Section | REQUIRED | 
| | 5.2) | | | 
$ AZ O $2 += + 
Available Spectrum Batch Request (Section 4.5.3) 
A a S AZ O $2 +------- + 
| Parameter | Type | Requirement | Notes | 
| Name | | | 
A A RES A AA $ += + 
| deviceDesc | DeviceDescriptor (Section | REQUIRED | 
| | 5.2) | | | 
$ AZ O R-—----------- Ho + 
DeviceDescriptor (Section 5.2) 
$ Ho ===> $2 AZ O + 
| Parameter Name | Type | Requirement | Notes 
$ Ho ===> $ $ + 
| serialNumber | string | REQUIRED | Specifies a device’s | 
| | | | serial number. See | 
Section 5.2. 
fccId string REQUIRED Specifies a device's 
| | | | FCC certification ID | 
| | | | (Section 9.2.2.1). | 
| fccTvbdDeviceType | string | REQUIRED | Specifies the FCC | 
| | | | Device Type (Section | 
9.2.2.2) of TV-band 
white-space device, as 
| | | | defined by the FCC | 
| | | | rules. | 
A Ho ===> $ a i + 
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The following table lists additional requirements for DeviceOwner 
(Section 5.5) parameter values. 


DeviceOwner (Section 5.5) 
BEEN A A A E OTR 
| Additional Requirement 
| Name | 
== + 
| The owner is required to contain the 
| formatted name of an individual or 
| organization using the "fn" property. When 
+ 


entry also is required to contain the "kind" 
property, with a value of "org". 

The operator entry is required to contain the 
following properties for the contact person 
responsible for the device's operation: "fn", | 
"adr", "tel", and "email". 
———  Á—— ae a A A A in a a A a A a a ee A a Neg in ws + 


| 
| 
| 
the name is that of an organization, the | 
| 
| 


operator vCard 


+ 
| 
| 
+ 
| 
| 
| 
| 
| 
| 

+ 


+ eh lt e 


9.1.2.2. European Telecommunications Standards Institute (ETSI) 
For the additional parameters that start with the "etsi" prefix, see 
PAWS Parameters Registry Initial Contents (Section 9.2.2) for more 
information. 


Ruleset identifier:  ETSI-EN-301-598-1.1.1 


Specification document(s): This ruleset refers to the ETSI 
Harmonised Standard [ETSI-EN-301-598] established by ETSI. 


Additional Parameter Requirements 
Each of the following tables defines additional parameters for the 


indicated PAWS message. Note that the Requirement column lists ETSI, 
not PAWS, requirements/optionality rules. 
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| Parameter Name | 

| Ra | 
Requirement 

| Notes 


serialNumber 
string 
REQUIRED 
Specifies a device’s serial number (Section 5.2). 


manufacturerId 
string 
REQUIRED 
Specifies a device's manufacturer's identifier 
(Section 5.2). 


modellId 
string 
REQUIRED 
Specifies a device's model identifier (Section 5.2). 


| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| etsiEnDeviceType | 
| string | 
| REQUIRED | 
| Specifies the device’s ETSI device type (Section 9.2.2.3). | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 


etsiEnDeviceEmissionsClass 
string 
REQUIRED 
Specifies the device’s ETSI device emissions class 
(Section 9.2.2.4). 


etsiEnTechnologyId 
string 
REQUIRED 
Specifies the device's ETSI technology ID (Section 9.2.2.5). 


etsiEnDeviceCategory 
string 
REQUIRED 
Specifies the device's ETSI device category (Section 9.2.2.6). 
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AVAIL_SPECTRUM_REQ (Section 4.5.1) 


+ Se ree eer eee 
| Parameter 

| Name 

+ ————— —————— 
| requestType 


string OPTIONAL 
Spectrum request type. If 
Specified, the only valid 
value is, "Generic Slave", 
and the Database is required 


| 
to respond with generic | 
| 
| 


—— + —— + 


Modifies the available- | 


| operating parameters for any 
| Slave Device. 
+ 


+ + 
| | 
| | 
+ + 
| | 
| | 
| | 
| | 
| | 
| | 
+ + 


Available Spectrum Batch Request (Section 4.5.3) 


+ inni qund Vii Seg Nis rp ini Sr: Se qum iii eee m 
| Parameter 
| Name 


OPTIONAL Modifies the available- | 
spectrum request type. If | 
specified, the only valid | 
value is, "Generic Slave", | 
and the Database is required | 
to respond with generic 
operating parameters for any 
Slave Device. | 

A A A sr + 


+ + 
| | 
| | 
+ + 
| | 
| | 
| | 
| | 
| | 
| | 
+ + 


+ — 


The following tables define additional requirements for the 
DeviceDescriptor (Section 5.2) and RulesetInfo (Section 5.6) 
parameters that appear in the AVAIL_SPECTRUM_RESP (Section 4.5.2) and 
AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4) messages. Note that this 
means the Database is modifying the DeviceDescriptor sent by the 
Master Device to return device-specific restrictions. 
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Parameter Name 
Type 
Requirement 
Notes 


needsSpectrumReport 
boolean 
REQUIRED 
The Database is required to set this to true to indicate 
the device must report spectrum usage. 


maxTotalBwHz 
float 
REQUIRED 
Specifies a constraint on total allowed bandwidth. 


maxCont iguousBwHz 
float 
REQUIRED 
Specifies a constraint on total allowed contiguous 
bandwidth. 


etsiEnSimultaneousChannelOpera 
string 
REQUIRED 
Specifies a constraint on simultaneous channel operation 
(Section 9.2.2.7). If it is not provided, the default 
is "om 


RulesetInfo (Section 5.6) 


Parameter Name 


Specifies a const 
on maximum locati 


maxLocationChange 


+ + + 
| | | 
------------------ 4+-------4-------------4-------------------------+ 
| | | 
| | | 
| | | 
+ + + 


that 


value 


raint 
on 


et al. Standards Track [Page 77] 


RFC 7545 PAWS May 2015 


9.2. PAWS Parameters Registry 
This specification establishes the "PAWS Parameters Registry". 


Additional parameters for inclusion in PAWS requests, responses, or 
sub-messages are registered on the advice of one or more Designated 
Experts, with Specification Required [RFC5226]. 


The Designated Expert should avoid duplication, i.e., avoid adding a 
new parameter when an existing one suffices. When a set of 
parameters is added in support of a new ruleset (Section 9.1), the 
parameters should share a common prefix that reflects the ruleset ID. 
The prefix may be omitted, of course, if a parameter has more general 
applicability. Similarly, when a parameter is not associated with a 
ruleset, the Designated Expert should ensure that the parameter name 
does not have a prefix that is used by existing ruleset parameters 
(e.g., "fcc", "etsi") or that is the initials of an organization that 
has not yet registered anything, but reasonably might. 


The PAWS Parameters Registry includes the following: 'Parameter 
name’, 'Parameter usage location’, and 'Specification document(s)’. 


9.2.1. Registration Template 
Parameter name: The name of the parameter (e.g., "example"). 


Parameter usage location: The location(s) where the parameter can be 
used. The possible locations are the named structures defined in 
"Protocol Functionalities" (Section 4) and "Protocol Parameters" 
(Section 5). 


Specification document(s): Reference to the document that specifies 
the parameter, preferably including a URI that can be used to 
retrieve a copy of the document. An indication of the relevant 
sections also may be included, but is not required. 


9.2.2. Initial Registry Contents 


The PAWS Parameters Registry enables protocol extensibility to 
support any regulatory domain and ruleset. The initial contents of 
the registry, however, include only FCC-specific and ETSI-specific 
entries, because, as of this writing, they are the only regulatory 
domains that have established rules. There is no intent to restrict 
the protocol to any particular set of authorities. 


The initial contents of the PAWS Parameters Registry are listed 
below; each section corresponds to a row of the registry. 
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9.222250 PCC ID 
Parameter name:  fccId 
Parameter usage location:  DeviceDescriptor (Section 5.2) 
Specification document(s): This document. Specifies the device's 
FCC certification identifier. A valid FCC ID is limited to 19 
characters in the ASCII value range, as proposed in FCC 
Administration Topics Review [FCC-Review-2012-10]. For the 
purposes of the PAWS protocol, the maximum length of the fccId 
value is 32 octets. 
9.2.2.2. FCC Device Type 
Parameter name:  fccTvbaDeviceType 
Parameter usage location:  DeviceDescriptor (Section 5.2) 
Specification document(s): This document.  Specifies the TV-band 
white-space device type, as defined by the FCC. Valid values are 
"FIXED", "MODE 1", and "MODE 2". 
9.2.2.3. ETSI Device Type 
Parameter name:  etsiEnDeviceType 
Parameter usage location:  DeviceDescriptor (Section 5.2) 
Specification document(s): Specifies the white-space device type, as 
defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. Valid 
values are single-letter strings, such as "A", "B", etc. Consult 
the documentation for details about the device types. 
9.2.2.4. ETSI Device Emissions Class 
Parameter name:  etsiEnDeviceEmissionsClass 
Parameter usage location:  DeviceDescriptor (Section 5.2) 
Specification document(s): Specifies the white-space device 
emissions class, as defined by the ETSI Harmonised Standard 
[ETSI-EN-301-598], that characterizes the out-of-block emissions 
of the device. The values are represented by numeric strings, 


such as "1", "2", "3", etc. Consult the documentation for details 
about emissions classes. 
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9.2.2.5. ETSI Technology Identifier 
Parameter name:  etsiEnTechnologyId 


Parameter usage location:  DeviceDescriptor (Section 5.2) 


Specification document(s): Specifies the white-space device 
technology identifier, as defined by the ETSI Harmonised Standard 
[ETSI-EN-301-598]. The maximum length of the string value is 64 
octets. Consult the documentation for valid values. 


9.2.2.6. ETSI Device Category 
Parameter name: etsiEnDeviceCategory 
Parameter usage location: DeviceDescriptor (Section 5.2) 
Specification document(s): Specifies the white-space device 
category, as defined by the ETSI Harmonised Standard 
[ETSI-EN-301-598]. Valid values are the strings "master" and 
"Slave". It is case insensitive. 


9.2.2.7. ETSI Simultaneous Channel Operation Restriction 


Parameter name:  etsiEnSimultaneousChannelOperationRestriction 


Parameter usage location:  SpectrumSpec (Section 5.9) 

Specification document(s):  Specifies the constraint on the device 
maximum total EIRP, as defined by the ETSI Harmonised Standard 
[ETSI-EN-301-598]. The values are represented by numeric strings, 


such as "0", "1", etc. Consult the documentation for the 
specification of the power constraint corresponding to each 
parameter value. 


9.3. PAWS Error Code Registry 
This specification establishes the "PAWS Error Code Registry". 


Additional error codes for inclusion in PAWS error messages are 
registered on the advice of one or more Designated Experts, with 
Specification Required [RFC5226]. 


Error codes are intended to be used for automated error handling by 


devices. Before approval, the Designated Expert should consider 
whether a device would handle the new error code differently from an 
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existing error code, or whether the difference could be communicated 
effectively to the end-user via the "reason" parameter of the Error 
(Section 5.17) object. 


The PAWS Error Code Registry includes the following: 'Code', 'Name', 
"Description and Additional Parameters’, and 'Specification 
Document(s)’. 


1. Registration Template 


Code: Integer value of the error code. The value MUST be an 
unassigned value in the range -32768 to 32767, inclusive. 


Name: Name of the error. 


Description and Additional Parameters: Description of the error and 
its associated parameters, if any. It also lists additional 
parameters that are returned in the data portion of the error (see 
Section 5.17). New parameters MUST be registered separately in 
the PAWS Parameters Registry, as described by Section 9.2. 


.2. Initial Registry Contents 


Initial registry contents are defined in the Error Codes 
Table (Table 1). 


The registry will also include the error-code categories describing 
-100s, -200s, and -300s as a note (see "Error Codes" (Section 5.17)). 


Security Considerations 


PAWS is a protocol whereby a Master Device requests a schedule of 
available spectrum at its location (or location of its Slave Devices) 
before it (they) can operate using those frequencies. Whereas the 
information provided by the Database must be accurate and conform to 
the applicable ruleset, the Database cannot enforce, through the 
protocol, that a client device uses only the spectrum it provided. 

In other words, devices can put energy in the air and cause 
interference without asking the Database. Hence, PAWS security 
considerations do not include protection against malicious use of the 
white-space spectrum. For more detailed information on specific 
requirements and security considerations associated with PAWS, see 
"Protocol to Access White-Space (PAWS) Databases: Use Cases and 
Requirements" [RFC6953]. 
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By 
to 


o 


using PAWS, the Master Device and the Database expose themselves 
the following risks: 


Accuracy: The Master Device receives incorrect spectrum- 
availability information. 


Privacy: 


* An unauthorized entity intercepts identifying data for the 
Master Device or its Slave Devices, such as serial number and 
location. 


* Where Databases are required to take device registrations and/ 
or maintain request logs, there could be unauthorized access to 
such information. 


Protection from these risks depends on the success of the following 
steps: 


Ly 


Chen, 


The Master Device must determine the address of a proper 
Database. 


The Master Device must connect to the proper Database. 


The Database must determine or compute accurate spectrum- 
availability information. 


PAWS messages must be transmitted unmodified between the Database 
and the Master Device. 


PAWS messages must be encrypted between the Database and the 
Master Device to prevent exposing private information. 


For a Slave Device, the spectrum-availability information also 
must be transmitted unmodified and securely between the Master 
Device and the Slave Device. 


When a Listing Server is required, any attack that would prevent 
reaching a Listing Server would result in all devices relying on 
that Listing Server ceasing their use of any white space. 


No future extensions to PAWS can allow the return of sensitive 
information, such as device information or logs. 


The Database must not allow unauthorized access to device 


information and request logs and should publish and implement 
privacy policies regarding their use. 
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Of these, only steps 1, 2, 4, 5, and 8 are within the scope of this 
document. This document addresses step 1 by allowing static 
provisioning of one or more trusted Databases; dynamic provisioning 
is out of scope. Step 3 is dependent on specific database 
implementations and rulesets and is outside the scope of this 
document. Step 6 requires a protocol between master and slave 
devices and is thus outside the scope of this document. 


Use of "HTTP Over TLS" [RFC2818], assuming the PKI used is not 
compromised, ensures steps 2, 4, and 5, as detailed in the following 
sections: 


o "Assurance of Proper Database" (Section 10.1) 
o "Protection against Modification" (Section 10.2) 
o "Protection against Eavesdropping" (Section 10.3) 


Any specification for an alternate transport MUST define mechanisms 
that ensure each of these steps. 


In addition to the privacy risks described above, information 
provided in DeviceDescriptor (Section 5.2) and DeviceOwner 

(Section 5.5), along with device location, may allow a database 
administrator to track the activity and location of a device and its 
user over time. Risks of secondary use of such tracking information, 
including sharing with third parties, require out-of-band mitigation, 
such as public statements or contractual terms. Furthermore, while 
it is understandable that regulators require DeviceOwner information 
for higher-power fixed white-space devices, for privacy concerns, 
regulators should not require DeviceOwner information for mobile 
devices. Similarly, regulators should require, and implementations 
should provide, device location at a level of granularity only as 
precise as necessary to support accurate database responses. 


1. Assurance of Proper Database 


This document assumes that the Database is contacted using a domain 
name or an IP address. Using HTTP over TLS, the Database 
authenticates its identity, either as a domain name or IP address, to 
the Master Device by presenting a certificate containing that 
identifier as a "subjectAltName" (i.e., as a dNSName or IP address). 
If the Master Device has external information as to the expected 
identity or credentials of the proper Database (e.g., a certificate 
fingerprint), checks of the subjectAltName MAY be omitted. Note that 
in order for the presented certificate to be valid at the client, the 
client must be able to validate the certificate. In particular, the 
validation path of the certificate must end in one of the client's 
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trust anchors, even if that trust anchor is the Database’s 
certificate. A Master Device should allow for the fact that a 
Database can change its Certification Authorities (CAs) over time. 


.2. Protection against Modification 


To prevent a PAWS response message from being modified en route, 
messages must be transmitted over an integrity-protected channel. 
Using HTTP over TLS, the channel will be protected by appropriate 
cipher suites. 


3. Protection against Eavesdropping 


Using HTTP over TLS, messages protected by appropriate cipher suites 
are also protected from eavesdropping or otherwise unrestricted 
reading by unauthorized parties en route. 


4. Client Authentication Considerations 


Although the Database can inform a device of available spectrum it 
can use, the Database cannot enforce that the Master Device uses only 
(or any of) those frequencies. Indeed, a malicious device can 
operate without ever contacting a Database. Note also that, whereas 
a malicious device may send fraudulent SPECTRUM_USE_NOTIFY 

(Section 4.5.5) messages, in the regulatory domains that have 
established rules, such notifications do not change the available- 
spectrum answers, so no harm can result from such messages. 
Consequently, client authentication is not required for the core PAWS 
(although it may be required by specific regulatory domains). 


Depending on a prior relationship between a Database and Master 
Device, the Database MAY require client authentication. TLS provides 
client authentication, but there are some considerations: 


o The Database must nominate acceptable CAs, and the Master Device 
must have a certificate rooted at one of those CAs. 


o As indicated in Section 3.2 of "HTTP Over TLS" [RFC2818], the TLS 
client authentication procedure only determines that the device 
has a certificate chain rooted in an appropriate CA (or a self- 
signed certificate). The Database would not know what the client 
identity ought to be, unless it has some external source of 
information. Distribution and management of such information, 
including revocation lists, are outside the scope of this 
document. 
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o Authentication schemes are secure only to the extent that secrets 
or certificates are kept secure. When there are a vast number of 
deployed devices using PAWS, the possibility that device keys will 
not leak becomes small. Implementations should consider how to 
manage the system in the eventuality that there is a leak. 
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Appendix A. Database Listing Server Support 


As discussed in "Database Discovery" (Section 4.1), some regulatory 
domains support the preconfiguration of devices with the URI of a 
listing server, to which devices can connect to obtain a list of 
Databases certified by the regulatory domain. Regulatory domains may 
require the device to periodically contact the Database Listing 
Server to validate and/or update its list of certified Databases. If 
the device is unable to validate its list of certified Databases 
within the required period, regulatory rules may require the device 
to treat this inability as equivalent to the device having no 
available spectrum. 


A sample JSON response from a Database Listing Server might be 
represented as follows: 


{ 


"lastUpdateTime": "2014-06-28T10:00:002", 
"maxRefreshMinutes": 1440 
"dbs": [ 
{ 
"name": "Some Operator", 
"üris"s [ 
{ 
"uri": "https://example.some.operator.com", 
"protocol": "paws" 


), 


), 


} 


The parameters in this sample message are: 


lastUpdateTime: The time at which the database entries were last 
updated. 
maxRefreshMinutes: The maximum interval, expressed in minutes, that 


is allowed between device requests to the Database Listing Server. 


dbs: A list of entries for certified Databases, each containing the 
following 


name: The name of the database operator. 
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uris: One or more URIs for each Database, allowing a Database to 
support more than one protocol. 


uri, protocol: Each protocol supported by a certified Database is 
associated with a separate URI (PAWS protocol URI shown). 
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